Compiled by Steven Borrelli https://bsky.app/profile/stefanoborrelli.bsky.social
Go to the directory with the image you want to work with. Run a Docker container with that directory mounted:
docker run -it --privileged -v /dev:/dev -v (pwd):/tmp --workdir /tmp ubuntu bash
(replace (pwd) with "$PWD" if using bash instead of fish)
See this thread for an explanation of why --privileged and -v /dev:/dev are required. The need for the latter can be avoided with this alrternative workaround.
In the container, assuming that $IMAGE_FILE is the name of your image file:
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
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
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:
| # one or the other, NOT both | |
| [url "https://github"] | |
| insteadOf = git://github | |
| # or | |
| [url "[email protected]:"] | |
| insteadOf = git://github |
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.
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:
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
-staticflag does, but I'm pretty sure that's not how you link to a library. Let me RTFM a bit.
Minutes later...
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.