Sur les distribs disposant de python < 2.7.9 (ubuntu 14.04 par exemple), les modules ansible apt_key et apt_repository ne gèrent pas les urls en HTTPS.

example:

       fatal: [localhost]: FAILED! => {"changed": false, "msg": "Failed to validate the SSL certificate for packages.elastic.co:443. Make sure your managed systems have a valid CA certificate installed. If the website serving the url uses SNI you need python >= 2.7.9 on your managed machine  (the python executable used (/usr/bin/python) is version: 2.7.6 (default, Nov 13 2018, 12:45:42) [GCC 4.8.4]) or you can install the `urllib3`, `pyOpenSSL`, `ndg-httpsclient`, and `pyasn1` python modules to perform SNI verification in python >= 2.6. You can use validate_certs=False if you do not need to confirm the servers identity but this is unsafe and not recommended. Paths checked for this platform: /etc/ssl/certs, /etc/pki/ca-trust/extracted/pem, /etc/pki/tls/certs, /usr/share/ca-certificates/cacert.org, /etc/ansible. The exception msg was: hostname 'packages.elastic.co' doesn't match 'e.sni.fastly.net'."}

Il est nécessaire d'installer les packages python-urllib3, python-openssl, python-pyasn1, python-pip et pip ndg-httpsclient pour que cela soit fonctionnel.

example:

- name: Debian - ensure python-urllib3, python-openssl, python-pyasn1 & python-pip are installed
  apt:
    name: python-urllib3,python-openssl,python-pyasn1,python-pip
    state: present
  when: ansible_distribution_release == "trusty"

- name: Debian - ensure ndg-httpsclient pip is installed
  pip:
    name: ndg-httpsclient
    state: present
  when: ansible_distribution_release == "trusty"

Un outil tout simple en go développé par un collègue qui vérifie toute les 60 secondes le status d'une PR GitHub et renvoie SUCCESS quand tout les checks définis sur la PR sont OK.

Prérequis: Créer un token GitHub disposant du scope repo:status

$ go get github.com/crazybus/pratus
$ export GITHUB_TOKEN=xxxxxxx
$ pratus https://github.com/Crazybus/pratus/pulls/1
Checking status of pull request 1 in Crazybus/pratus every 60 seconds
......
PR finished with state: success

Petit procédure pour générer une clé GPG avec Keybase sur MacOS et l'utiliser pour signer ses commits GitHub

Une nouvelle vulnérabilité a été découverte dans runc qui permet aux containers Docker qui tournent en tant que root de devenir root sure le système hôte.

Il faut mettre à jour Docker (dernière version: 18.09.02).

Il est également recommandé de ne jamais faire tourner de containers en tant que root et de contrôler les images Docker qui tournent en production.

EDIT: voire également la communication côté K8S (https://kubernetes.io/blog/2019/02/11/runc-and-cve-2019-5736/) et AWS (https://aws.amazon.com/security/security-bulletins/AWS-2019-002/)

Pour afficher toutes les variables ansible d'un host: ansible -m debug -a "var=hostvars[inventory_hostname]" localhost

C'est super utile pour débuguer les variables réellement prises en compte quand on a des variables qui s'overrident entre les host_vars, group_vars, ...

Les jobs CI peuvent être très consomateurs en IOPS, notamment lors des phases de téléchargement des artifacts (maven :) ou docker par exemple...) ou lors du build. Une CI déployée sur des instances EC2 avec des volumes EBS standards (gp2) peut connaitre des temps de réponse particulièrement dégradés lorsqu'elle à dépassé sa capacité de burst et qu'elle est limité en IOPS.

Il est interessant dans ce contexte de monitorer l'EBS Burst Balance sur ces volumes.

En cas de performance limitée par les IOPS EBS, il y a 3 solutions:

• augmenter la taille des EBS pour bénéficier de d'un nombre d'IOPS plus important (nb IOPS = 3 x nb GB)
• passer sur des EBS de type io1 pour bénéficier d'un nombre d'IOPS garanti (souvent moins intéressant en terme de coûts)
• utiliser des instances disposant de SSD internes à la place des EBS (ex: c5d ou m5d instances)

Un top-like pour kubernetes qui permet de monitorer en temps réel les resources K8S mais aussi d'afficher ou éditer leurs définition, d'afficher les logs des pods ou de lancer un kubectl exec dessus.

Les Operators K8S permettent de déployer un produit (ex: Prometheus, ETCD out Vault...) sur K8S et de gérer toute la configuration sous forme d'objets K8S custom (CRDs). C'est selon moi un des concepts les plus prometteurs de K8S qui permet notamment de déployer le monitoring Prometheus en même temps qu'une appli dans K8S, mais aussi d'automatiser le provisioning de ressources externes cloud nécessaires au fonctionnement de l'application (bucket S3, record DNS ou base DynamoDB par exemple). L'article présente les Operators plus en détail et liste les 120 Operators existant actuellement avec le niveau de maturité de chacun.

Quelques optimisations pour utiliser EKS en production

Les prérequis a connaitre pour utiliser K8S avec le cloud provider AWS qui permet de provisionner automatiquement de ressources ELB et EBS pour les services de type Load balancer et les PersistentVolumes

Pager Duty vient de publier ses procédures de gestion d'incident en Open Source.
Voire également les slides ici: https://response.pagerduty.com/training/courses/incident_response/

Le getting started officiel Hashicorp pour déployer un cluster EKS avec Terraform.
Le code est ici: https://github.com/terraform-providers/terraform-provider-aws/tree/master/examples/eks-getting-started

EDIT:

NOTE: The usage of the specific kubernetes.io/cluster/ resource tags below are required for EKS and Kubernetes to discover and manage networking resources.
NOTE: The usage of the specific kubernetes.io/cluster/ resource tag below is required for EKS and Kubernetes to discover and manage compute resources.

voir également: https://github.com/kubernetes/cloud-provider-aws/blob/8f6e1e3d2cfa20a0deac088b9c4022d433500369/pkg/cloudprovider/providers/aws/tags.go#L30-L52

Je n'ai pas trouvé de doc officielle claire indiquant les tags à mettre en place sur les ressources AWS, mais après avoir passé 2 jours à débugguer pourquoi mes ELB ne se provisionnaient pas, puis pourquoi mes Nodes n'arrivaient pas à joindre le cluster EKS, je confirme que ces tags sont très importants à ajouter sur les ressources suivantes:

• VPC
• Subnets
• Security Groups
• Instances EC2

Pour installer une appli via brew à partir d'une PR pas encore mergée dans master:

brew pull <github_pr_number>
brew install <formula_name>

L'auteur propose de se passer de bastion pour accéder aux resources dans le cloud en ouvrant le port SSH uniquement lorsque l'on a besoin de se connecter à une instance grace à un script qui génère dynamiquement des Security Groups.
La démarche est interessante mais n'apporte pas de solutions pour les instances situés dans des subnets privés et ne disposant pas d'IP publiques.

Une bonne introduction au déploiement d'infra sur Azure avec Ansible et Terraform. A noter l'utilisation du module Ansible pour Terraform.

Suivre à la lettre le principe DRY peut être source d'over-engineering et conduire à créer du code moins lisible/maintenable inutilement. Avec WET, la duplication de code est autorisé lorsque ce code est utilisée 2 fois, le refactoring du code pour limiter la redondance n'intervient qu'au bout de la 3ème utilisation du code.

Un petit tuto pour créer un cluster AKS (K8S managé Azure) avec Terraform.

Un catalogue de helm charts façon DockerHub

Les règles de la communication asynchrone chez GitHub:

1. Prefer asynchronous communication
2. Don’t underestimate high-fidelity mediums
3. Nobody gets fired for opening an issue
4. Copy teams, not team members
5. Be mindful of noise
6. Use checklists to make blockers explicit
7. Issues are organization-wide todos
8. Master the gentle bump
9. Keep discussions logically distinct
10. There’s only one way to change something
11. Secrets, secrets, are no fun
12. Surface work early for feedback
13. If you can’t diff it, don’t use it
14. Pull requests are community property
15. Don’t ping, just ask
    Bonus: Overcompensate for tone
    Double bonus: If it has a URL, link to it

Une liste exhaustive de bonnes pratiques à mettre en place avant de déployer une infrastructure en production sur AWS