This blog benefits a lot from the helpful guidance from mdda and wangruohui.
The strategy presented below applies to the default desktop environment GNOME3 of Fedora 27, but may not work for others such as KDE Plasma. For instance, KDE tends to crash after installation of NVIDIA drivers. Actually, this is also confirmed by my own recent experience with Fedora KDE Plasma.
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
Sometimes, we have to access git repositories over SSL and the server only provides a self-signed certificate 🙈. Although there are ways to increase the trust level for the self-signed certificate (https://confluence.atlassian.com/fishkb/unable-to-clone-git-repository-due-to-self-signed-certificate-376838977.html, https://confluence.atlassian.com/bitbucketserverkb/resolving-ssl-self-signed-certificate-errors-806029899.html), my recommendation is to just ignore SSL verification alltogether.
Prepend GIT_SSL_NO_VERIFY=true before every git command run to skip SSL verification. This is particularly useful if you haven't checked out the repository yet.
Run git config http.sslVerify false to disable SSL verification if you're working with a checked out repository already.
If you hate git submodule, then you may want to give git subtree a try.
When you want to use a subtree, you add the subtree to an existing repository where the subtree is a reference to another repository url and branch/tag. This add command adds all the code and files into the main repository locally; it's not just a reference to a remote repo.
When you stage and commit files for the main repo, it will add all of the remote files in the same operation. The subtree checkout will pull all the files in one pass, so there is no need to try and connect to another repo to get the portion of subtree files, because they were already included in the main repo.
Let's say you already have a git repository with at least one commit. You can add another repository into this respository like this:
namespaces - overview of Linux namespaces http://man7.org/linux/man-pages/man7/namespaces.7.html
mount_namespaces - overview of Linux mount namespaces
Some notes about:
These notes assume some basic background knowledge about memory management, ulimits and cgroups.
Here are the simple steps needed to create a deployment from your local GIT repository to a server based on this in-depth tutorial.
You are developing in a working-copy on your local machine, lets say on the master branch. Most of the time, people would push code to a remote server like github.com or gitlab.com and pull or export it to a production server. Or you use a service like deepl.io to act upon a Web-Hook that's triggered that service.
| #!/usr/bin/env bash | |
| # Generate RSA private key | |
| openssl genrsa -out private_key.pem 1024 |