22 Aug 2017
Fedora People
Casper: Unités systemd avec docker
Une fois encore le couple systemd-docker nous montre son efficacité... redoutable. J'ai pû monter un service en quelques minutes sans prise de tête ou complication imprévue; certes la partie zone DNS et reverse proxy était déjà en place, mais quand même. Je résumerais l'histoire en 4 étapes.
Veni
Le premier reflexe à avoir quand on veut monter un nouveau service, est de chercher sur la registry Docker officielle une image potable, et vérifier son Dockerfile pour voir si elle emballe pas quelques abérations. Moi je cherchais une image du service Searx, et je suis tombé sur une perle rare.
Vidi
L'image docker est basée sur Alpine Linux 3.6, elle n'a pas de volumes donc pas de données persistantes, et elle n'expose qu'un seul port, plus simple tu meurs. Petit plus, elle n'embarque pas les dépendances de compilation, elle se contente de compiler le programme sans faire de choses tordues avant ou après. Le script run.sh procède visiblement à quelques ajustements de la config du programme, notament la génération d'une clé d'authentification, qui sera regénérée à chaque lancement. Soit.
Vici \o/
Il ne reste plus qu'à concrétiser tout ça dans son terminal...
# docker pull wonderfall/searx
L'unité systemd aura les fonctionnalités suivantes:
- Lancer le processus dans le container et créer le container
- Le container utilise le serveur DNS de OpenDNS (fixe un bug avec NetworkManager et dnsmasq)
- Le container écoute sur le port 8089 de l'interface localhost (important)
- L'url de base est passée en variable d'environnement
- Envoi du signal reload au processus cloisonné
- Tuer le processus dans son container et laisser le container à l'abandon
- un nouveau container avec un nouveau nom sera créé au prochain redémarrage
# cat /etc/systemd/system/searx-casper-site.service
[Unit]
Description=Searx search engine
After=docker.service
[Service]
Restart=always
ExecStart=/usr/bin/docker run -i --dns 208.67.222.222 -p 127.0.0.1:8089:8888 \
-e BASE_URL=https://search.casperlefantom.net \
wonderfall/searx:latest
ExecReload=/usr/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
J'insiste sur le fait que vos containers doivent écouter seulement sur l'interface localhost pour des raisons de sécurité. Si le container écoute sur l'interface ethernet, alors son port d'écoute sera accessible depuis n'importe où sur Internet. Firewalld ne pourra rien faire pour vous. J'ai 2 reverses proxy devant, je serais bien embêté si on pouvait les bypasser >-)
# systemctl daemon-reload
# systemctl enable searx-casper-site.service
# systemctl start searx-casper-site.service
Les logs du programme sont automatiquement récupérés par Journald. L'étape de suppression des containers sans processus actif est relègué à une opération de nettoyage manuel. Je n'ai malheureusement pas trouvé d'autre solution, des disques trop lent sont assez problématiques et provoquent des erreurs de système de fichier en cours d'utilisation.
22 Aug 2017 4:17am GMT
Sarup Banskota: Gaming Willpower
Watching my daily lifestyle evolve over the last two years, I have recently developed an amateur interest in human habits and willpower.
Habits are routines we go through without thinking much about because we're used to doing them successfully for a relatively long time. Willpower is the fuel that we can use to drive involuntary routines to completion. Habit is what drives us towards another cup of sugar drink against our meal plan's wishes, willpower is what helps prevents it.
Habits are formed through a repetitive anticipation trigger → routine → satisfaction cycle. A Starbucks builds the anticipation of good coffee, and we're programmed to walk towards it and grab a cuppa to win some satisfaction.
Strong willpower is often needed for routines whose results and success rates are not clear or instant. It is easier to form the habit of using a particular toothpaste every day, because we anticipate the cool-fresh feeling within minutes. It is difficult to form the habit of doing an intensive workout everyday at 6pm, because the anticipation is of pain and the result (weight loss, sexy legs, abs) is far away, making it less attractive and harder to visualise.
Stanford University psychologist Kelly McGonigal wrote a book on this topic. I read parts of it, and the key takeaway for me was that just like physical power:
- Willpower has a daily cap. Within a willpower day, we gotta budget what we spend it on. Otherwise, we will lose our willpower to trivial things, and lose focus on what's most important
- Willpower can be trained and the cap can be increased. Much like going to the gym or exposing ourselves to the sport, if we consciously work on gaming our willpower allocation, we get better at it, and more of the activities that demanded higher willpower will inch towards becoming habits
- Willpower days can be short - they don't necessarily have to be as long as human days - naps and small victories can help replenish willpower and restart the cycle willpower chartwillpower chart
- After observing my own behaviour for 6 months, I discovered that there are willpower peaks when I wake up or when I successfully complete work.
Naturally, I wanted to take advantage of willpower peaks to get difficult things done. I also wanted to discover ways to boost my willpower when it was dropping. Through some reading and subsequent experimentation, what I found to work well for me is to list down which activities in my day consume more willpower than others, and to organise them around observed peaks. Ironically, willpower is also needed to follow this organised plan, because there is usually inertia that prevents one from frequently changing what they're currently doing.
Here are some example activities (classifications can wary from person to person):
- Habit activities (no willpower needed) - brushing teeth, replying to instant messages, calling a loved one to deliver good news, eating easily accessible food when a little hungry
- Low willpower activities - catching the bus to work, cleaning up after cooking, making your bed before leaving for work, gorging on food that's not easily accessible
- High willpower productive activities - waking up, working out, solving a difficult math problem, writing a blogpost 😉
- High willpower chores - this is a special category comprising tasks that need high willpower, but which I'd rather not do now, in the interest of spending time on other important things - groceries, paying bills, booking flights or hotels. However not doing them sufficiently sooner makes them expensive in the near future, and with time they often pile up and become urgent. The bright side about chores is that they're often small victories.
So a good plan could start as follows:
Wake up (only if you know you've slept enough) - this usually consumes substantial willpower. To make up, we need to achieve a small victory now: maybe lay out clothes for office, make the bed, get the laundry started Follow it up with a few habit activities - brush teeth, breakfast (kept within easy reach). This period also allows time for forming a list of what are some unique high willpower activities for the day (leftover difficult work from yesterday etc) Time for a high willpower activity! Get cracking on JIRA-615 😉 Hopefully it works out and serves as a small victory. Small victories will usually elevate willpower levels again In the event of a high willpower activity not working out, that's when we have to be careful - small failures can be pretty dangerous for the mood. Therefore, a suitable thing to do now is a chore that doesn't involve decision making. e.g making a known bill payment, making a pre-decided lunch (more on this later). As we already know by now, a brainless chore will provide a small victory, and elevate willpower levels Recently, I'm trying to get better at keeping an inventory of brainless chores. When I experience a small failure and willpower is low, I pick one of the chores and strike them off to unlock a small victory.
Making weekly decisions in bulk during high willpower period is helpful. For example, recently I've been trying to plan in advance what meals I'm going to prepare through the week, and shop for ingredients with a defined shopping list at a time when I'm seeking a small victory. This saves me a few food decisions during the work week, keeps me well fed, and I get a free weekly brainless chore to exchange for small victory.
Call me crazy, but now I also go one level further by distributing breakfast and dinner ingredients in the home refrigerator and lunch in the office one. This allows for easy access when I need them, which means low willpower towards preparing meals. This in turn means I avoid skipping meals. This one habit has allowed me to not skip a single meal in the last one week (usually I always skip at least breakfast or lunch or both).
If you're feeling like giving the willpower gaming a try, here are the two key takeaways from this post:
Plan your day around your personal willpower peaks for maximum productivity. When willpower is high, do high willpower tasks. When willpower is low, aim for brainless tasks that lead to small victories Move towards making habits. Habits follow an anticipation trigger → routine → satisfaction cycle. By making triggers easily visible, and satisfaction better defined, you convert high willpower activities to lower willpower ones. Through practice, you can make the routine brainless - voila you just made a habit
22 Aug 2017 12:00am GMT
21 Aug 2017
Fedora People
Adam Young: Customing the KubeVirt Manifests
My cloud may not look like your cloud. The contract between the application deployment and the Kubernetes installation is a set of manifest files that guide Kubernetes in selecting, naming, and exposing resources. In order to make the generation of the Manifests sane in KubeVirt, we've provided a little bit of build system support.
The manifest files are templatized in a jinja style. I say style, because the actual template string replacement is done using simmple bash scripting. Regardless of the mechanism, it should not be hard for a developer to understand what happens. I'll assume that you have your source code checked out in $GOPATH/src/kubevirt.io/kubevirt/
The template files exist in the manifests subdirectory. Mine looks like this:
haproxy.yaml.in squid.yaml.in virt-manifest.yaml.in
iscsi-demo-target.yaml.in virt-api.yaml.in vm-resource.yaml.in
libvirt.yaml.in virt-controller.yaml.in
migration-resource.yaml.in virt-handler.yaml.in
The simplest way to generate a set of actual manifest files is to run make manifests
make manifests
./hack/build-manifests.sh
$ ls -l manifests/*yaml
-rw-rw-r--. 1 ayoung ayoung 672 Aug 21 10:17 manifests/haproxy.yaml
-rw-rw-r--. 1 ayoung ayoung 2384 Aug 21 10:17 manifests/iscsi-demo-target.yaml
-rw-rw-r--. 1 ayoung ayoung 1707 Aug 21 10:17 manifests/libvirt.yaml
-rw-rw-r--. 1 ayoung ayoung 256 Aug 21 10:17 manifests/migration-resource.yaml
-rw-rw-r--. 1 ayoung ayoung 709 Aug 21 10:17 manifests/squid.yaml
-rw-rw-r--. 1 ayoung ayoung 832 Aug 21 10:17 manifests/virt-api.yaml
-rw-rw-r--. 1 ayoung ayoung 987 Aug 21 10:17 manifests/virt-controller.yaml
-rw-rw-r--. 1 ayoung ayoung 954 Aug 21 10:17 manifests/virt-handler.yaml
-rw-rw-r--. 1 ayoung ayoung 1650 Aug 21 10:17 manifests/virt-manifest.yaml
-rw-rw-r--. 1 ayoung ayoung 228 Aug 21 10:17 manifests/vm-resource.yaml
Looking at the difference between, say the virt-api template and final yaml file:
$ diff -u manifests/virt-api.yaml.in manifests/virt-api.yaml
--- manifests/virt-api.yaml.in 2017-07-20 13:29:00.532916101 -0400
+++ manifests/virt-api.yaml 2017-08-21 10:17:10.533038861 -0400
@@ -7,7 +7,7 @@
- port: 8183
targetPort: virt-api
externalIPs :
- - "{{ master_ip }}"
+ - "192.168.200.2"
selector:
app: virt-api
---
@@ -23,14 +23,14 @@
spec:
containers:
- name: virt-api
- image: {{ docker_prefix }}/virt-api:{{ docker_tag }}
+ image: kubevirt/virt-api:latest
imagePullPolicy: IfNotPresent
command:
- "/virt-api"
- "--port"
- "8183"
- "--spice-proxy"
- - "{{ master_ip }}:3128"
+ - "192.168.200.2:3128"
ports:
- containerPort: 8183
name: "virt-api"
@@ -38,4 +38,4 @@
securityContext:
runAsNonRoot: true
nodeSelector:
- kubernetes.io/hostname: {{ primary_node_name }}
+ kubernetes.io/hostname: master
make manifests, it turns out, just calls a bash script ./hack/build-manifests.sh. This script uses two files to determine the values to use for template string substitution. First, the defaults: hack/config-default.sh. This is where master_ip get the value of 192.168.200.2. This file also gives priority to the $DOCKER_TAG environment variable. However, if you need to customize values further, you can create and manage them in the file hack/config-local.sh. The goal is that any of the keys from the -default file that are specified in the hack/config-local.sh will use the value from the latter file. The set of keys with their defaults (as of this writing) that you can customize are:
binaries="cmd/virt-controller cmd/virt-launcher cmd/virt-handler cmd/virt-api cmd/virtctl cmd/virt-manifest"
docker_images="cmd/virt-controller cmd/virt-launcher cmd/virt-handler cmd/virt-api cmd/virt-manifest images/haproxy images/iscsi-demo-target-tgtd images/vm-killer images/libvirt-kubevirt images/spice-proxy cmd/virt-migrator cmd/registry-disk-v1alpha images/cirros-registry-disk-demo"
optional_docker_images="cmd/registry-disk-v1alpha images/fedora-atomic-registry-disk-demo"
docker_prefix=kubevirt
docker_tag=${DOCKER_TAG:-latest}
manifest_templates="`ls manifests/*.in`"
master_ip=192.168.200.2
master_port=8184
network_provider=weave
primary_nic=${primary_nic:-eth1}
primary_node_name=${primary_node_name:-master}
Not all of these are for Manifest files. The docker_images key is used in selecting the set of generating Docker images to generate in a command called from a different section of the Makefile. The network_provider is used in the Vagrant setup, and so on.However, most of the values are used in the manifest files. So, If I want to set a master IP Address of 10.10.10.10, I would have a hack/config-local.sh file that looks like this:
master_ip=10.10.10.10
$ diff -u manifests/virt-api.yaml.in manifests/virt-api.yaml
--- manifests/virt-api.yaml.in 2017-07-20 13:29:00.532916101 -0400
+++ manifests/virt-api.yaml 2017-08-21 10:42:28.434742371 -0400
@@ -7,7 +7,7 @@
- port: 8183
targetPort: virt-api
externalIPs :
- - "{{ master_ip }}"
+ - "10.10.10.10"
selector:
app: virt-api
---
@@ -23,14 +23,14 @@
spec:
containers:
- name: virt-api
- image: {{ docker_prefix }}/virt-api:{{ docker_tag }}
+ image: kubevirt/virt-api:latest
imagePullPolicy: IfNotPresent
command:
- "/virt-api"
- "--port"
- "8183"
- "--spice-proxy"
- - "{{ master_ip }}:3128"
+ - "10.10.10.10:3128"
ports:
- containerPort: 8183
name: "virt-api"
@@ -38,4 +38,4 @@
securityContext:
runAsNonRoot: true
nodeSelector:
- kubernetes.io/hostname: {{ primary_node_name }}
+ kubernetes.io/hostname: master
21 Aug 2017 5:02pm GMT