409 liens privés
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.
Plein de ressources pour k8s.
"""
In the following post, we’re going to take a tour of two of the leading Docker orchestration frameworks out there: ECS (Elastic Container Service) by AWS, and Kubernetes, an orchestration framework which began at Google and became open source later.
"""
We got a winner.
Un article qui tape juste.
"""
Kubernetes includes a cool feature called namespaces, which enable you to manage different environments within the same cluster. For example, you can have different test and staging environments in the same cluster of machines, potentially saving resources. You can also run different types of server, batch, or other jobs in the same cluster without worrying about them affecting each other.
"""
http://kubernetes.io/v1.0/docs/user-guide/namespaces.html
"""
Using RabbitMQ on EC2 is quite similar running it on other platforms. However, the are certain minor aspects to EC2 that need to be accounted for. They primarily have to do with hostnames and their resolution.
"""
petit tuto en Français pour jouer avec 'redis cluster' qui arrive dans la version 3 de redis.
docs officielles:
Un howto qui explique comment gèrer la crise dans le cas d'un cluster consul down.
Méthode de résolution pas très rapide car il s'agit de trouver quels nodes sont down.
Ma méthode crade/rapide à l'aide de saltstack:
"""
salt * cmd.run 'rm -v /var/cache/consul/raft/peers.json'
salt * service.restart consul
"""
script bash bien utile pour faire un genre de clusterssh mais dans un vrai terminal, grâce à tmux.
exemple:
./tm ms web{1..4}.kikoo.com foo.bar.com # ouvrira un tmux splitté sur web1.kikoo.com web2.kikoo.com web3.kikoo.com et web4.kikoo.com et foo.bar.com permettant de commander ces serveurs en même temps grâce à un tmux dont les panneaux sont synchronisés.
Twitter utilise Redis pour le cache de la timeline.
En complément, voir aussi cette présentation par une employée de Twitter: https://www.youtube.com/watch?v=rP9EKvWt0zo
ça parle de haute dispo avec redis
voir aussi http://redis.io/topics/sentinel
Les commentaires valent le coup.
J'y ai notamment découvert 'serf' (https://github.com/hashicorp/serf).
Cet outil permet de faire de l'autodiscovery pour ajouter des noeuds automatiquement dans des pools.
ça peut être des pools de serveurs web (haproxy), ou de serveurs memcached (twemproxy).
Bref, c'est pratique pour faire de l'auto-scaling.
Ca fait aussi d'autres trucs qui peuvent (à mon sens) faire éventuellement double emploi avec un outil de gestion de configuration centralisé (saltstack, puppet, chef...).