This guide describes how to bootstrap new Production Core OS Cluster as High Availability Service in a 15 minutes with using etcd2, Fleet, Flannel, Confd, Nginx Balancer and Docker.
#!/bin/bash | |
set -e | |
sudo rm -f /etc/update-motd.d/10-help-text | |
sudo rm -f /etc/update-motd.d/51-cloudguest | |
sudo rm -f /etc/update-motd.d/91-release-upgrade | |
echo -e "[sysinfo]\nexclude_sysinfo_plugins = LandscapeLink" | sudo tee /etc/landscape/client.conf | |
echo deb https://get.docker.com/ubuntu docker main | sudo tee /etc/apt/sources.list.d/docker.list | |
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9 |
sudo apt-get update && sudo apt-get upgrade -y | |
sudo apt-get install build-essential dkms | |
wget "http://sourceforge.net/projects/e1000/files/ixgbevf stable/3.1.2/ixgbevf-3.1.2.tar.gz" | |
tar -xzf ixgbevf-3.1.2.tar.gz | |
sudo mv ixgbevf-3.1.2 /usr/src | |
sudo cat<<EOH > /usr/src/ixgbevf-3.1.2/dkms.conf | |
PACKAGE_NAME="ixgbevf" | |
PACKAGE_VERSION="3.1.2" | |
CLEAN="cd src/; make clean" | |
MAKE="cd src/; make BUILD_KERNEL=${kernelver}" |
Friend: I tried looking at static linking in Mac OS X and it seems nearly impossible. Take a look at this http://stackoverflow.com/a/3801032
Me: I have no idea what that
-static
flag does, but I'm pretty sure that's not how you link to a library. Let me RTFM a bit.
Minutes later...
Sometimes you may want to undo a whole commit with all changes. Instead of going through all the changes manually, you can simply tell git to revert a commit, which does not even have to be the last one. Reverting a commit means to create a new commit that undoes all changes that were made in the bad commit. Just like above, the bad commit remains there, but it no longer affects the the current master and any future commits on top of it.
git revert {commit_id}
Deleting the last commit is the easiest case. Let's say we have a remote origin with branch master that currently points to commit dd61ab32. We want to remove the top commit. Translated to git terminology, we want to force the master branch of the origin remote repository to the parent of dd61ab32:
Set up Kubernetes on 3 Debian Jessie virtual machines: One master. Two nodes. Additionally do this without any "magic" so that what is required to be running to make everything work is plain and obvious.
We will be using flannel for the inter-machine networking layer. Mainly because it is useful and it seems to be pretty popular.
# one or the other, NOT both | |
[url "https://github"] | |
insteadOf = git://github | |
# or | |
[url "[email protected]:"] | |
insteadOf = git://github |
This gist is based on the information available at golang/dep, only slightly more terse and annotated with a few notes and links primarily for my own personal benefit. It's public in case this information is helpful to anyone else as well.
I initially advocated Glide for my team and then, more recently, vndr. I've also taken the approach of exerting direct control over what goes into vendor/
in my Dockerfiles, and also work from
isolated GOPATH environments on my system per project to ensure that dependencies are explicitly found under vendor/
.
At the end of the day, vendoring (and committing vendor/
) is about being in control of your dependencies and being able to achieve reproducible builds. While you can achieve this manually, things that are nice to have in a vendoring tool include:
The official guide for setting up Kubernetes using kubeadm
works well for clusters of one architecture. But, the main problem that crops up is the kube-proxy
image defaults to the architecture of the master node (where kubeadm
was run in the first place).
This causes issues when arm
nodes join the cluster, as they will try to execute the amd64
version of kube-proxy
, and will fail.
It turns out that the pod running kube-proxy
is configured using a DaemonSet. With a small edit to the configuration, it's possible to create multiple DaemonSets—one for each architecture.
Follow the instructions at https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/ for setting up the master node. I've been using Weave Net as the network plugin; it see
The big reason to do this is that LLDB has no ability to "follow-fork-mode child", in other words, a multi-process target that doesn't have a single-process mode (or, a bug that only manifests when in multi-process mode) is going to be difficult or impossible to debug, especially if you have to run the target over and over in order to make the bug manifest. If you have a repeatable bug, no big deal, break on the fork
from the parent process and attach to the child in a second lldb instance. Otherwise, read on.
Don't make the mistake of thinking you can just brew install gdb
. Currently this is version 10.2 and it's mostly broken, with at least two annoying bugs as of April 29th 2021, but the big one is https://sourceware.org/bugzilla/show_bug.cgi?id=24069
$ xcode-select install # install the XCode command-line tools