PuppetConf 2016. Kubernetes pour les administrateurs système. 3e partie

PuppetConf 2016. Kubernetes pour les administrateurs système. Partie 1 de
PuppetConf 2016. Kubernetes pour les administrateurs système. Partie 2

Nous prenons l'application Homards et créons une nouvelle image avec de nouvelles exigences. Tout d'abord, entrez la commande de déploiement $ kubectl apply –f deployments / lobsters.yaml et envoyez l'application au cluster, qui doit effectuer des mises à jour continues pour chacune des instances d'application disponibles conformément à la stratégie de mise à jour. Tout d'abord, le système s'assure que chaque instance est opérationnelle, puis les détruit dans le jeu de conteneurs suivant.



Voyons comment cela a fonctionné. Pour ce faire, nous rechargeons le site, et maintenant le manque de points blancs fera le bonheur de notre marketeur.



En tant qu'administrateur système, vous pouvez dire: "Il n'y a pas de HTTPS ici, ces sites sont faciles à pirater, c'est dangereux!" Comment résoudre ce problème? Je pense que dans sa solution, Kubernetes peut agir comme un cadre qui permet à l'administrateur système de mettre en œuvre une approche créative du travail. Ce serait bien si je pouvais dire de manière déclarative: "Je veux obtenir le certificat Let's Encrypt pour ce site, mais je ne veux pas redéployer ce conteneur." Je veux le faire selon mes capacités, sans recourir à l'équipe de développement d'applications pour obtenir de l'aide. Kubernetes le permet, car il prend en charge les extensions personnalisées.

J'ai parlé de kubectl, des pods, des déploiements, des services, mais nous avons également des types personnalisés - des types de ressources personnalisés qui peuvent être obtenus auprès de Puppet. Chez Puppet, nous pouvons définir de nouveaux types, afin que nous puissions utiliser ce système pour notre travail.
Voyons à quoi cela ressemble dans Kubernetes. Tout d'abord, nous avons besoin d'une extension pour les certificats, voici à quoi cela ressemble. Ici, nous avons notre propre espace de noms hightower.com, dans lequel se trouve l'objet certifié.



Nous créons une nouvelle extension dans Kubernetes en utilisant la commande $ kubectl create –f extensions / certificate.yaml, et le stockage est automatiquement créé dans le backend et cet état est géré.



L'apparition de ce nouvel objet m'oblige à utiliser un nouvel outil qui suit les modifications et prend des mesures sur l'objet certificat. Autrement dit, cet outil en arrière-plan devrait interagir avec Let's Encrypt et obtenir un certificat valide. Pour cela, j'utilise secret - je vais montrer très rapidement comment cela se fait.

Donc, nous avons besoin d'un nouveau sous, et je vais montrer quelle est la différence par rapport au code précédent. J'ajoute nginx à un conteneur existant, nous n'avons donc pas besoin de contacter l'équipe de développement. Nous continuons à utiliser HTTPS en plaçant simplement le conteneur tout en haut du foyer existant.



Ce conteneur accepte le trafic HTTPS et a besoin d'un fichier de configuration pour interagir avec le backend. J'ai également besoin de certains certificats que nginx télécharge à partir du système de fichiers, donc les variables d'environnement ne fonctionnent pas ici. Je n'ai pas écrit nginx, donc je ne peux pas lui faire faire ça.



J'ajoute donc juste ce contenant juste à l'intérieur du foyer et je me tourne vers deux secrets.



Le premier et le plus important secret est le certificat TLS, qui devrait provenir de Let's Encrypt. Je ne vais pas signaler Let's Encrypt à mon application, je le signale à mon système. Je veux contrôler cette abstraction. Alors maintenant, je dois créer un fichier de configuration pour nginx. Il s'agit du fichier de configuration principal qui ressemble à ceci.

Le port 443 est spécifié ici et SSL est activé, qui recherche ces 2 fichiers dans le système de fichiers, capture le trafic et l'envoie à l'hôte local 127.0.0.1 {000.



C'est exactement ce que ma candidature écoute. Maintenant, je vais créer configmap - la carte de configuration nginx en utilisant la commande suivante.



Maintenant, en utilisant la commande $ kubectl get configmaps, je place le configmap "nginx" sur le système avec le même nom que le disque.



Ensuite, vous devez créer un secret, je vous le rappelle encore - je veux que tout soit automatisé, et je ne veux pas interférer dans le processus d'obtention des certificats. Pour ce faire, je déploie un outil appelé «kube-cert-manager», et voici le résultat.



Nous essayons d'obtenir un certificat Let's Encrypt valide, auquel mon navigateur fera confiance, et de l'insérer dans le backend comme secret. Par conséquent, pour mon foyer, il n'y aura aucune différence dans le fait que nous ayons complété son contenu. Si vous vous souvenez, tout cela se fait en créant un type personnalisé dans Puppet.

C'est peut-être une mauvaise idée, mais maintenant je vais essayer de démarrer le contrôleur, qui fonctionnera en arrière-plan. Nous ne compilons pas, nous ne créons pas de fournisseurs, ce démon fonctionne juste en arrière-plan et surveille les changements. Dès que l'objet certificat apparaît, il le reçoit avec Let's Encrypt et l'insère dans le système en temps réel sans aucun délai. Donc, j'utilise la commande suivante.



Cette chose a également du stockage, afin que nous puissions enregistrer tout ce dont nous avons besoin. Il faut quelques secondes au gestionnaire de certification kube-cert-manager pour commencer à travailler.



La prochaine chose que nous devons faire est de créer un objet de certificat. C'est ce que je me définis, c'est mon propre schéma. Je crée une nouvelle chose que Kubernetes n'a pas rencontrée jusqu'à présent, qui dit que je peux obtenir un certificat pour le domaine lobsters.com.



Il y a une adresse e-mail et d'autres informations nécessaires pour Let's Encrypt pour me donner un certificat valide. Let's Encrypt m'enverra un jeton d'échange pour voir si je possède vraiment ce domaine et je devrai appliquer ce jeton à mon DNS dans Google Cloud. Si le chèque réussit, ils me remettront un vrai certificat que j'insérerai dans mon système de fichiers. Voyons comment cela fonctionne en entrant la commande $ kubectl get pods.



Comme vous pouvez le voir, le gestionnaire de certificats fonctionne toujours. Voyons les informations détaillées sur ce processus à l'aide de la commande $ kubectl describe pods kube-cert-manager, en insérant le nom du conteneur à partir de la première ligne de code.



Vous voyez que le travail se fait dans les délais. Pour le moment, le serveur crée un volume qui, après vérification et formatage, sera monté sur ce serveur. Pendant que ce processus est en cours, nous pouvons aller plus loin et terminer notre travail.

J'entre la commande kubectl create –f certificats / lobsters.yaml et j'obtiens le résultat suivant.



Ensuite, j'utilise une commande qui vous permet d'afficher les journaux de plusieurs conteneurs. Je vais souligner celui qui se rapporte à mon objet.



Maintenant, un enregistrement DNS est en cours de création dans mon serveur DNS basé sur le cloud. Si je rafraîchis la page affichée ici, je verrai un nouveau jeton d'échange avec l'extension .txt.



J'ai donc reçu un jeton de Let's Encrypt et maintenant je vérifie que cet enregistrement DNS a été distribué à tous les serveurs autorisés avant de dire à Let's Encrypt de vérifier cette entrée de texte dans mon domaine.



Si cela fonctionne, ils me renverront un certificat valide. La démonstration DNS en temps réel est une mauvaise idée. Ouais, on obtient enfin le certificat. Let's Encrypt a remarqué que le certificat avait disparu de Kubernetes et l'a inséré là. C'est super, car maintenant j'ai déjà une interface de demande de certificat pour tout ce qui fonctionne dans Kubernetes.

Pour m'assurer que tout fonctionne correctement, j'entre la commande $ kubectl get secrets et nous voyons un secret pour lobsters.hightowerlabs.com.



J'utilise maintenant la commande $ kubectl delete secrets lobsters.hightowerlabs.com, car il s'agit d'un système déclaratif, nous ne supprimons pas l'objet de certificat, mais nous nous débarrassons du secret qui lui est associé situé dans Kubernetes. Par conséquent, nous devons nous assurer que lorsque cet élément est supprimé, le système renverra le certificat Let's Encrypt lui-même. C'est très similaire à ce que nous faisons dans Puppet, seulement ici, cela se produit en ligne.

Après nous être assurés que tout fonctionne, nous redéployons notre application nginx appelée «lobsters-secure», qui assurera la sécurité du nouveau domaine. Son image est similaire à la version précédente, mais la différence est que nous mettons nginx ici. Nginx récupère le lien secret, puis Kubernetes l'insère dans le système de fichiers, à la suite de quoi j'obtiens un certificat valide pour un domaine spécifique.

Pour ce faire, j'entre la commande $ kubectl apply –f deployments / lobsters-secure.yaml en utilisant le même nom afin que cette commande écrase l'état existant. Ensuite, la commande $ kubectl get pods est utilisée, ce qui montre que la mise à jour continue est en cours ici, car nos définitions ont changé.

Une fois la mise à jour terminée, il est clair que la nouvelle définition est utilisée pour cette application. Je veux m'assurer que le certificat est valide pour notre nom DNS, pour lequel j'entre la commande $ kubectl get svc et copie l'adresse IP du site des homards.



En allant dans l'onglet Google Cloud, vous pouvez voir que cette adresse correspond à l'adresse correspondant au nom de domaine lobsters.hightowerlabs.com. Maintenant, si vous tapez lobsters.hightowerlabs.com dans la barre d'adresse de votre navigateur , vous pouvez voir que nous avons un certificat valide.



Merci, c'est tout ce que je voulais dire dans le rapport Kubernetes for System Admins.


Un peu de publicité :)


Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis des VPS basés sur le cloud pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur les VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?

All Articles