Jon Warbrick, July 2014, V3.2 (for Ansible 1.7)
First one found from of
URL="http://stackoverflow.com/" | |
# store the whole response with the status at the and | |
HTTP_RESPONSE=$(curl --silent --write-out "HTTPSTATUS:%{http_code}" -X POST $URL) | |
# extract the body | |
HTTP_BODY=$(echo $HTTP_RESPONSE | sed -e 's/HTTPSTATUS\:.*//g') | |
# extract the status | |
HTTP_STATUS=$(echo $HTTP_RESPONSE | tr -d '\n' | sed -e 's/.*HTTPSTATUS://') |
#!/usr/bin/env bash | |
# this can be useful when developing against a custom DNS server, or | |
# for example, if you made a change to the DNS settings of a domain, and you | |
# know the authoritative nameserver IP address for a domain, you could use this | |
# to bypass the intermediate DNS cache, and apply an HTTP request using the new | |
# DNS settings supplied by your specified (authoritative) nameserver | |
curl --dns-servers <DNSIP,DNSIP> url.com |
Jon Warbrick, July 2014, V3.2 (for Ansible 1.7)
First one found from of
#! /bin/bash | |
function valid_required_envs() { | |
# Configs | |
required_envs=(KUBE_CONTEXT KUBE_SERVER) | |
# Securities | |
required_envs+=(KUBE_CERTIFICATE_AUTHORITY) | |
required_envs+=(KUBE_CLIENT_CERTIFICATE KUBE_CLIENT_KEY) | |
errors=() |
#!/usr/bin/env bash | |
git branch -r | grep -v '\->' | while read remote; do git branch --track "${remote#origin/}" "$remote"; done | |
git fetch --all | |
git pull --all |
When setting these options consider the following:
sudo grep max_children /var/log/php?.?-fpm.log.1 /var/log/php?.?-fpm.log
For those who have been using kops for a while should know the upgrade from 1.11 to 1.12 poses a greater risk, as it will upgrade etcd2 to etcd3.
Since this upgrade is disruptive to the control plane (master nodes), although brief, it's still something we take very seriously because nearly all the Buffer production services are running on this single cluster. We felt a more thorough backup process than the currently implemented Heptio Velero was needed.
To my surprises, my Google searches didn't yield any useful result on how to carry out the backup steps. To be fair, there are a few articles that are specifically for backing up master nodes created by kubeedm but nothing too concrete for `kop
kubectl -n kube-system patch daemonset myDaemonset -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
kubectl -n kube-system patch daemonset myDaemonset --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'