397 liens privés
nouveau standard du logging
Logging is a critical component on production environments that allow us to perform monitoring and data analysis. While applications runs at scale, the Logging layer also needs to scale and...
TL;DR;
Ca fait du bien autant d'honnêteté sur ce sujet, surtout venant d'une core dev Docker.
En parlant de DeviceMapper, elle dit :
It works great on RedHat.
Clairement. J'ai tenté sur debian, j'ai ouvert 2 bug requests (#21330 #21304)) et je suis retourné sur aufs.
A lire, cette màj:
Update: The conclusion of this post talks about managing Docker kittens with Ansible; I no longer do that, but instead use Amazon ECS with Terraform. Docker has stabilized a lot since my early experiences as well. However some things like custom kernel parameters (e.g. for Redis) will always be a limitation. I’ll write a new blog post on how I use ECS and Terraform soon.
Huhu.. Toujours est-il que ces schedulers docker sont encore bien jeunes pour y faire tourner de la prod. ECS semble stable mais il souffre d'un manque de fonctionnalité pour faire du stateful:
- Pas de notion d'affinité / d'anti-affinité entre tâches, même si on trouve ce workaround dégueu: https://github.com/aws/amazon-ecs-agent/issues/212#issuecomment-143591755 (cf. https://jeekajoo.eu/links/?-RNUJQ)
- Pas de support des drivers de stockage: https://github.com/aws/amazon-ecs-agent/issues/236 . Rédhibitoire pour faire tourner une base de données mysql ou postgresql.
- On doit se farcir le discovery des services via un consul / etcd qu'on va gérer soit-même. C'est possible, mais hors process et faillible car en dehors du contrôle des services dont le rôle est de respawner des tâches. cf https://jeekajoo.eu/links/?5Rqafg
Yes, two tasks from the same task definition can be started on the same container instance as long as none of the consumed resources conflict. If you want to prevent this behavior, the easiest way is to assign a host port in the task definition. Assigning a host port will consume a resource (a port) on the host that is then unavailable when the second task needs to be placed.
Haha, voici la méthode pour créer une sorte d'anti-affinité entre des tâches dans un cluster ECS ; pour faire en sorte que 2 tâches ne se retrouvent pas sur la même instance (vm).
D'après le commentaire juste en dessous, ils bossent pour proposer une option. Dans le futur, on peut donc espèrer un truc éminemment plus propre que cette gruikerie réseau.
REX-Ray delivers persistent storage access for container runtimes including those provided by Docker, Mesos and others. It is designed to enable advanced storage functionality across common storage, virtualization and cloud platforms.
Un driver de stockage docker, codé par EMC en go, qui permet d'apporter de la persistance aux containers qui sont par nature jetables, alors que ce qu'on souhaite parfois faire tourner dedans n'est en rien stateless..
Code: https://github.com/emccode/rexray
Outil similaire: Flocker
via https://kvaes.wordpress.com/2016/02/11/docker-storage-patterns-for-persistence/ qui explique certains concepts à ce sujet
On peut avoir besoin de lancer une tâche sur chaque instance à leur démarrage, notamment pour démarrer la partie monitoring ou bien pour lancer un service de discovery comme consul.
Ce billet explique comment.
TL;DR; ?
- assigner un rôle IAM aux instances pour leur donner le droit de lancer des tâches ECS
- éditer un script bash dans le "User data" pour lancer un
aws ecs start-task --task-definition <task_name:version> ...
Le seul soucis, c'est que si la tâche foire, il n'y aura rien pour la relancer. C'est notamment le rôle des "services" mais ceux-ci sont destinés à un cluster.
« Non docker n'est pas la "silver bullet", et il a d'ailleurs ses propres défauts. Petit tour des trucs qui clochent dans Docker. »
Avec Nicolas De Loof (Cloudbees) qui, dans cet épisode, fait un clin d'oeil au "Joueur du grenier". Déja 1000 abonnés à sa chaîne youtube.
This article proposes a design pattern modeled after “Immutable Infrastructure”, something I call “Immutable Delivery”. There has been a lot of debate and discussion about the usage of the term “I...
There’s been a welcome focus in the Docker community recently around image size. Smaller image sizes are being championed by Docker and by the community. When many images clock in at multi-100 MB a...
En gros ils rappelent que chaque instruction d'un Dockerfile donne lieu à un commit. Ils expliquent donc comment éviter des commits qui font que les images résultantes sont inutilement volumineuses.
rkt / coreOS / baremetal
Plein de ressources pour k8s.
Presentation de Borg, cluster de conteneur conçu/utilisé par google en interne et utilisant lmctfy (https://github.com/google/lmctfy) pour le moteur de conteneur. Ils utilisent Borg sur du bare-metal. D'après https://speakerdeck.com/jbeda/containers-at-scale, ils lancent 2 milliards de conteneurs par semaine.
De Borg, ils ont pondu Kubernetes qui est open-source et qui est basé cette fois-ci sur Docker.
Il propose d'ailleurs un Kubernetes intégré, avec "Google Container Engine". Ce dernier tourne sur des VM Google Cloud Engine, dont l'hyperviseur est KVM.
Rien ne dit s'ils vont utiliser Kubernetes pour leur propres besoin... rien ne dit non plus quelles sont les différences à part le moteur de conteneur, car Borg n'est pas open-source.
Cette présentation a eu lieu lors de DotScale 2015 (http://2015.dotscale.io/).
"""
Docker managed the unikernels just like Linux containers but without needing to deploy a traditional operating system!
"""
Meet unikernels, meet the future.
"Nousmotards" explique son utilisation de git + jenkins + ansible + packer + docker + docker registry + consul + consul template + haproxy.
/!\ Je préfère préciser que je ne soutiens en aucun cas leur pauvre conception de la femme. Ni les motos d'ailleurs /!\
"""
bane - Custom AppArmor profile generator for docker containers
"""
Générateur de profil AppArmor pour contraindre les permissions, par exemple d'éxécution ou d'écriture, à l'intérieur des containers.
AppArmor agit au niveau de ce que l'on appele les "capabilities" [1] au niveau kernel donc. Comme le host et les containers partagent le même, le profil est chargé niveau host.
Il est automatiquement parsé (syntax check) et sauvegardé dans /etc/apparmor.d/containers/.
Démo (vidéo dégueulasse nécessitant flash) par l'auteure de cet outil, Jessie, qui est core dev chez Docker: https://www.periscope.tv/w/1djGXbgzbvRxZ
Le plus simple est de lire le README.md.
"""
Docker’s default storage driver on most Ubuntu installs is AUFS.
Don’t use it. Use Overlay instead. Here’s why.
"""
A ne pas confondre avec Overlay Networks (shaarlink précédent).