Je cherchais à déployer le même build sur un env de preprod et ensuite sur la prod si le build est ok
Ce qui se fait très bien "à l'ancienne" avec Jenkins/Bamboo :

• on a une étape de build qui va créé un artifact
• et une étape de deploy completement indépendante qui permet de déployer un artifact qu'on choisit sur un env en particulier

Je ne retrouvais pas cette logique dans les outils plus récents car le deploy est toujours lié au build donc je ne voyais pas comment faire..
La clé est dans la possibilité de pouvoir arrêter un job, de le mettre en pause pour pouvoir le déclencher plus tard si on le souhaite
Donc pour un commit push sur un master, le workflow va se déclencher...

• tests, builds...
• deploy sur preprod
• deploy sur prod en HOLD

Si on voit que tout est ok sur preprod, on peut venir resume le deploy prod ! on va utiliser le même build qu'on a testé sur la preprod

C'est le même principe, on veut check la preprod avant de déployer la prod en utilisant le même build, mais implémenté différement

L'équivalent chez circleci :
https://circleci.com/blog/manual-job-approval-and-scheduled-workflow-runs/
https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval

Et chez Jenkins (récent) :
https://jenkins.io/doc/pipeline/tour/deployment/#asking-for-human-input-to-proceed

Le nombre de pods par worker node dépend du type d'EC2 utilisé qui détermine combien d'interfaces secondaires on a à notre disposition et de combien d'ips sur chaque interfaces on peut allouer.

Exemple avec une t2.small, on a 2 interfaces secondaires et sur chacune on peut allouer 4 ips. On peut donc lancer 8 pods maximum sur une t2.small

Il faut aussi savoir qu'un cluster EKS va faire tourner de base quelques pods :

• un deployment pour coredns avec un replicaset=2 par défaut
• un daemonset spécifique à aws (awsnode)
• un daemonset pour le kubeproxy

Ce qui équivaut à 2 pods occupés sur chaque worker node (à cause des deux daemonset) et 2 pod supplémentaire lancé sur la totalité du cluster (pour coredns).

Il faut aussi compter un pod pour le dashboard, un pod pour le metrics-server et surement 2 pods pour l'external-dns, sans compter les ingress

Tout ça pour dire que ce n'est pas facile d'avoir un "petit" cluster EKS : on va vite être limité par le nombre d'ip qui est assez faible sur les EC2 les plus modestes et on va vite être obligé de lancer des EC2 supplémentaire juste pour avoir des ip

tweak volume pour perf docker sous mac

The Quickest Way to Show/Hide Hidden Files

Since the release of macOS Sierra, when in Finder, it is now possible to use the shortcut:

CMD + SHIFT + .

via arnaudb

Un retour d'xp sur EKS

olded by https://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/specifying-sensitive-data.html