erez-rabih

{
  "title": "Nginx Web",
  "services": {
    "query": {
      "list": {
        "0": {
          "query": "response:[200 TO 299]",
          "alias": "OK",
          "color": "#7EB26D",
          "id": 0,

ddossot

Alternative implementation of TcpIpJoinerOverAWS

This is a workaround for this Hazelcast issue.

To use the alternative TcpIpJoinerOverAWS:

• Remove hazelcast-cloud from your project's classpath,
• Add this class in your project or JAR it up if you prefer,
• Do not configure an accessKey nor a secretKey in Hazelcast's AwsConfig.

kelseyhightower

Single Node Kubernetes Cluster

sudo docker run -d --net=host --privileged --name=kubestack \
-v /sys:/sys:ro \
-v /:/rootfs:ro \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /var/run:/var/run:rw \
-v /var/lib/kubelet/:/var/lib/kubelet:rw \
-v /var/lib/docker/:/var/lib/docker:ro \

agonzalezro

cat $HOME/.docker/config.json|jq '.auths'|sed "s/http:/https:/g"|tr '\n' ' '|tr -d '[[:space:]]'|base64

mhausenblas

That's our RC:

$ cat ws-rc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: webserver-rc
spec:
  replicas: 5

selector:

ipedrazas

openssl pkcs12 -export -out certificate.pfx -inkey apiserver-key.pem -in apiserver.pem -certfile ca.pem
(set `test` as password)

curl -v -k -E ./certificate.pfx:test  https://172.17.4.101:443

rbranson

The point of this is to use cheap machines with small/slow storage to coordinate client requests while dedicating the machines with the big and fast storage to doing what they do best. I found that request coordination was contributing to about half the CPU usage on our Cassandra nodes, on average. Solid state storage is quite expensive, nearly doubling the cost of typical hardware. It also means that if people have control over hardware placement within the network, they can place proxy nodes closer to the client without impacting their storage footprint or fault tolerance characteristics.

This is accomplished in Cassandra by passing the -Dcassandra.join_ring=false option when the process is started. These nodes will connect to the seeds, cache the gossip data, load the schema, and begin listening for client requests. Messages like "/x.x.x.x is now UP!" will appear on the other nodes.

There are also some more practical benefits to this. Handling client requests caused us to push the NewSize of the heap up

ipedrazas

curl -k  \
 --header "Content-Type:application/merge-patch+json" \
 --header "Accept: application/json" \
 --header "Authorization: Bearer $TOKEN" \
 --request PATCH \
 --data '{ "metadata": {"labels": {"base": "coreOS"}}}' \
 $API_SERVER/api/v1/nodes/172.17.4.202

agonzalezro

Links were sourced from:

• http://kube.news/
• http://golangweekly.com/
• https://elixirweekly.net/
• & from twitter of course :)

And they are sorted by my own rating (~ fun at reading it & things I've learnt). Some of the links have auto explainable urls, to the ones that not I added the title to save you a click.

Go

acolyer

References from my QCon London 2016 Keynote

• The Morning Paper blog

Thinking Tools

• Scalability! But at what COST?
• Tachyon: Reliable, Memory Speed Storage for Cluster Computing
• Musketeer - Part I: What's the best data processing system?
• Musketeer - Part II: all for one, and one for all in data processing systems