AWS – Elastic Beanstalk – DevOps

Elastic Beanstalk est un service AWS gratuit (on ne paie que ce qu’on consomme sur les instances) qui permet de manager facilement un bout de cloud. Ce service s’adresse à ceux qui souhaitent deployer dans le cloud une application rapidement en laissant le soin du scaling à AWS (ça se se fait automatiquement). Donc si vous n’avez pas de besoin crucial de finesse de config sur vos environnements, EB est un bon choix. Objectif de cet article : déployer un site web en quelques lignes de commande sur AWS – EB. Staging et Prod. Je ne sais pas vous, mais d’habitude, pour lancer un POC ou un petit site rapide, je passe pas mal de temps à configurer et gérer mon environnement de production, et surtout mes déploiements. J’ai un VPS sur OVH qui me sert pour le moment de dev/prod (ce site étant sur ce serveur). Je passe par un classique sFTP pour uploader mes builds. J’ai toujours voulu automatiser ces tâches. C’est relativement facile depuis un mac ou linux, mais ça a longtemps été galère sur Windows. En ce qui concerne les outils en ligne de commande, j’y arrivais pas ou mal. De plus, mon VPS n’est pas du tout scalable. Du coup, j’ai mis un pied dans le cloud via Azure. Perso je trouve que c’est bien le bordel. Ca évolue régulièrement et j’ai pas de formation Azure. J’ai l’impression qu’il fait sortir l’artillerie lourde dès le début. Pour un dev comme moi, j’ai besoin d’un accès gratuit ou peu cher avec maitrise des coûts dès le départ. Azure dispose d’une CLI, on peut jouer avec. J’ai testé la création de deux instances VM avec du kubernetes, du docker, et tout un tas de trucs qui au final me coute un bras. Ya bien une offre Azure avec qq crédits, mais pour le moment j’ai pas encore trouvé qq chose à moins de 20 balles/mois (et c’est déjà trop !). Moi développeur, je veux tester avant tout, lancer un produit, monter en charge facilement, maitriser mes coûts et ensuite commencer à réfléchir à une architecture/infra « long life ». Amazon propose une offre gratuite sur 12 mois pour tester ses services. En gros on a le droit à des services, mais pour savoir « combien, comment, où, avec qui, tout ça », c’est pas simple (faut attendre la fin du mois, perso j’ai 18$ en 14 jours juste a tester ce qui suit…). On peut monter ses VMs comme je l’ai fait sur Azure, avec une CLI AWS ou sur la Console AWS, mais c’est vraiment long et au départ on a pas besoin d’une armada de trucs. Elastic Beanstalk est la pour ça. AWS EB va s’occuper de tout ce que je ne maitrise pas ou mal. Ce que je veux, c’est deux environnements de staging et de prod. Un site web + une base de données SQL. On couvre l’essentiel de mes besoins pour le moment et à mon avis, les vôtres aussi. Mise en bouche : Avant de commencer à jouer avec la CLI je vous propose deux vidéos intéressantes qui m’ont mis le pied à l’étrier : La première vidéo permet de créer un site web asp.net core mvc tout simple et de l’uploader sur AWS – EB en utilisant la console de management AWS. Cette dernière mal nommé car on pense à une console en ligne de commande. Il n’en est rien. C’est une interface web. Il est intéressant de commencer à se former via celle ci car elle permet de se faire une idée des services et fonctionnalités disponibles. De plus, lorsque nous passerons sur la CLI, c’est un bon moyen de s’assurer du résultat de nos commandes. Faut savoir qu’on peut aussi passer via une API web, donc programmer des trucs avec… La seconde vidéo nous montre comment connecter une base de données à notre site web. En gros le strict minimum pour un site web assez basique, le tout sur le cloud. Il vous faudra bien sur un compte AWS et une carte bancaire. Il existe des offres gratuites sur 12 mois. Il faut faire attention à ce qu’on choisit pour rester dans le pack « gratos ». La CLI – eb La commande line interface d’Elastic Beanstalk (doc officielle) permet d’administrer votre cloud EB comme si vous êtiez sur la console AWS, mais en ligne de commande… L’intérêt est d’automatiser certaines tâches. Le but est de pouvoir coder en dev sur une machine local et de deployer son code en 2 deux trois mouvements sur un environnement cloud Staging et Prod. Je pars du principe que vous avez votre site web de prêt (pour moi ce sera un site asp.net core). On se met à la racine de celui ci via votre terminal préféré. Ci dessus, la console AWS EB qui liste mes environnements et mes applications. Si vous avez fait les tutos des deux vidéos précédentes, vous allez reconnaitre Netcoredemo Le but est de refaire exactement la même chose en ligne de commande. Première commande : eb init Cette commande commence par créer un répertoire .elasticbeanstalk à la racine de votre projet (enfin si vous y êtiez lorsque vous l’avez taper). On y retrouvera quelques fichiers intéressant pour la suite. eb va vous demander les points suivant : Region : pour ma part eu-west-3 Choix de l’app (une existante ou une nouvelle) : une nouvelle App name : DemoDevOps Platform : il y a le choix, pour moi .net core on linux SSH : pour le moment non (c’est à envisager par contre) et biiimmmm : On constate que notre application toute fraîche n’a pas d’environnement d’exécution. Nous allons le créer avec la prochaine commande. Si on regarde dans le répertoire .elasticbeanstalk on y trouve un nouveau fichier config.yml. Il contient tout ce que nous venons de créer sous forme d’un fichier (manifest de deploiement). On verra plus tard qu’on passera via ce fichier pour aller encore plus vite. Deuxième commande : eb create Cette commande va créer un environnement pour notre…

Conteneuriser et exploiter un cluster via AKS

Dans cet article nous allons suivre le tutoriel de la doc de microsoft tutorial-kubernetes-prepare-app J’ai pour ma part totalement effacé toute resource sur Azure (free trial) pour partir d’une feuille blanche car certain nom de resource été similaire. Ce tuto part du principe que l’on a une application qui fonctionne en dev. On souhaite la conteneuriser, la distribuer sur un registry online puis s’en servir via AKS. Ensuite on verra comment scaler l’app. Ce tuto est plutot long, mais je pense complet sur les sujet essentiels.   1 – Création d’une image docker On va cloner une app de demo sur github, mais si vous avez la votre, prennez la. Ouvrez un terminal, créer un répertoire de travail et se mettre dedans puis taper : git clone https://github.com/Azure-Samples/azure-voting-app-redis.git L’image est très légère. Faut dire que le code aussi. En se rendant dans le repertoire azure-voting-app-redis on peut voir quelques fichiers dont un qui va particulièrement nous intéresser : docker-compose.yaml version: ‘3’ services:   azure-vote-back:     image: redis     container_name: azure-vote-back     ports:         – « 6379:6379 »   azure-vote-front:     build: ./azure-vote     image: azure-vote-front     container_name: azure-vote-front     environment:       REDIS: azure-vote-back     ports:         – « 8080:80 » Ce fichier est relativement simple. Nous avons deux services basées sur une image redis et une app web dont l’image est azure-vote-front. L’image Redis proviendra du registry Docker Hub (version officielle) et la seconde sera buildé avec un dockerfile situé dans le projet web azure-vote. Voici ce dockerfile : FROM tiangolo/uwsgi-nginx-flask:python3.6 RUN pip install redis ADD /azure-vote /app Ce dockerfile va créer un conteneur basé sur l’image tiangolo/uwsgi-nginx-flask (950 Mo) (avec python 3.6). On execute ensuite une commande pour installer redis (via python) et on ajoute le code source du site web dans un repertoire sur le conteneur nommé app. On a plus qu’a taper la commande docker-compose up -d ce qui va monter les deux images dans le registry local. Dans un premier temps cela va télécharger les image de  tiangolo et redis si vous ne les avez pas déjà sur votre poste. Ensuite docker-compose va builder l’image de notre app. (attention, il faudra la rebuilder pour la mettre a jour dans une prochaine image). La commande suivante va lister vos images locales : $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE azure-vote-front latest 9cc914e25834 40 seconds ago 694MB redis latest a1b99da73d05 7 days ago 106MB tiangolo/uwsgi-nginx-flask flask 788ca94b2313 9 months ago $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 82411933e8f9 azure-vote-front « /usr/bin/supervisord » 57 seconds ago Up 30 seconds 443/tcp, 0.0.0.0:8080->80/tcp azure-vote-front b68fed4b66b6 redis « docker-entrypoint… » 57 seconds ago Up 30 seconds 0.0.0.0:6379->6379/tcp azure-vote-back En lisant nos conteneurs lancé par docker on voit bien nos deux images. On a plus qu’à tester l’url http://localhost:8080 et on devrait voir notre app tourner localement! Un petit docker-compose down pour libérer ces process docker et cette partie est finie. 2 – Envoyer nos conteneurs vers Azure Container Registry La première chose à faire est de créer une instance d’Azure Container Registry (ACR) En premier lieu on créer le groupe de ressources : az group create –name myResourceGroup –location eastus Pour info celui ci n’apparaitra pas sur le portail pour le moment car il est vide. Il faut lui rajouter un élement. Voici la commande pour créer un ACR : az acr create –resource-group myResourceGroup –name myACR35 –sku Basic Le nom du registry doit être unique car il sera accessible publiquement via une url comme celle ci myacr.azurecr.io En tapant cette commande, azure nous indique que ce nom est déjà occupé et nous livre une adress web pour vérifier les nom existant. On va renommer noter myACR en qq chose de libre, myACR35 à l’air de passer : > az acr create –resource-group myResourceGroup –name myACR35 –sku Basic { « adminUserEnabled »: false, « creationDate »: « 2020-01-30T10:12:36.101431+00:00 », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries /myACR35 », « location »: « eastus », « loginServer »: « myacr35.azurecr.io », « name »: « myACR35 », « networkRuleSet »: null, « policies »: { « quarantinePolicy »: { « status »: « disabled » }, « retentionPolicy »: { « days »: 7, « lastUpdatedTime »: « 2020-01-30T10:12:37.145663+00:00 », « status »: « disabled » }, « trustPolicy »: { « status »: « disabled », « type »: « Notary » } }, « provisioningState »: « Succeeded », « resourceGroup »: « myResourceGroup », « sku »: { « name »: « Basic », « tier »: « Basic » }, « status »: null, « storageAccount »: null, « tags »: {}, « type »: « Microsoft.ContainerRegistry/registries » } L’ACR myACR35 étant créé on va s’y connecter : > az acr login –name myACR35 Uppercase characters are detected in the registry name. When using its server url in docker commands, to avoid authentication errors, use al l lowercase. Login Succeeded Le retour de cette commande nous indique qu’il serait préférable à l’avenir d’utiliser un  nom en minuscule. Balisage (tag) Pour utiliser l’image conteneur azure-vote-front avec ACR, on doit baliser cette image avec l’adresse du serveur de connexion de votre registre. Celle ci se trouve dans le retour json précedent : « loginServer »: « myacr35.azurecr.io » Si vous ne l’avez plus, vous pouvez l’obtenir avec la commande suivante : az acr list –resource-group myResourceGroup –query « [].{acrLoginServer:loginServer} » –output table À présent, étiquetez votre image azure-vote-front locale avec l’adresse myacr35.azurecr.io (en minuscule) du registre de conteneurs. Pour indiquer la version de l’image, ajoutez :v1 à la fin du nom de l’image :  docker tag azure-vote-front myacr35.azurecr.io/azure-vote-front:v1 PS D:\Kubernetes\AKSText2\azure-voting-app-redis> docker images REPOSITORY TAG IMAGE ID CREATED SIZE azure-vote-front latest df60d4cc1f96 About an hour ago 965MB myacr35.azurecr.io/azure-vote-front v1 df60d4cc1f96 About an hour ago 965MB On remarque alors qu’une nouvelle image est présente dans la liste (docker image) celle ci étant balisé sur notre serveur distant. Envoyer l’image docker push myacr35.azurecr.io/azure-vote-front:v1 On envoit notre image via la commande docker push. Cela peut prendre qq minutes suivant la taille de celle ci. Quand celle ci sera uploadé, on ira vérifier avec cette commande qui liste les images de notre repo de conteneur distant : > az acr repository list –name myacr35 –output table Result —————- azure-vote-front Notre image est bien sur notre Azure Container Registery myACR35. 3 – Déployer un cluster az aks create –resource-group myResourceGroup –name myAKSCluster –node-count 2 –generate-ssh-keys –attach-acr myacr35 Cette commande permet la création d’un cluster de 2 nodes branché sur le registre ACR que l’on vient de créer. Vous devriez voir au bout de qq minutes un retour en JSON : { « aadProfile »: null, « addonProfiles »: null, « agentPoolProfiles »: [ { « availabilityZones »: null, « count »: 2, « enableAutoScaling »: null, « enableNodePublicIp »: null, « maxCount »: null, « maxPods »: 110, « minCount »: null, « name »: « nodepool1 », « nodeTaints »: null, « orchestratorVersion »: « 1.14.8 », « osDiskSizeGb »: 100, « osType »: « Linux », « provisioningState »: « Succeeded », « scaleSetEvictionPolicy »: null, « scaleSetPriority »: null, « type »:…

AKS – gestion

Nous allons définir un état souhaité pour le cluster via un fichier de manifeste yaml. Le guide suivant https://docs.microsoft.com/fr-fr/azure/aks/kubernetes-walkthrough nous permet d’utiliser une app toute faite « Azure Vote » écrite en python ainsi qu’une instance Redis. Ces deux éléments sont conteneurisé et disponible sur une base de registre en ligne (docker hub) Le fichier manifeste va faire plusieurs grandes tâches : déploiement kubernetes service kubernetes Déploiement Kubernetes https://docs.microsoft.com/fr-fr/azure/aks/concepts-clusters-workloads#deployments-and-yaml-manifests C’est l’action de « copier » un conteneur sur un ou plusieurs nodes (suivant le nombre de replica). C’est le contrôleur de déploiement qui se charge de gérer les réplicas (création, destruction, mise à jour) Dans cette phase, on peut spécifier des limites de ressources sur l’UC ou la RAM et spécifier l’ouverture d’un port pour le conteneur. Services Kubernetes https://docs.microsoft.com/fr-fr/azure/aks/concepts-network#services Pour simplifier la configuration du réseau pour les charges de travail d’applications, Kubernetes utilise des services pour regrouper logiquement un ensemble de pods et fournir une connectivité réseau. Les types de service suivants sont disponibles : ClusterIP : crée une adresse IP interne pour une utilisation au sein du cluster AKS. NodePort : crée un mappage de port sur le nœud sous-jacent qui rend l’application accessible directement avec l’adresse IP du nœud et le port. LoadBalancer : crée une ressource d’équilibreur de charge Azure, configure une adresse IP externe et connecte les pods demandés au pool back-end d’équilibreurs de charge. ExternalName : crée une entrée DNS spécifique pour faciliter l’accès aux applications. Manifest apiVersion: apps/v1 kind: Deployment metadata:   name: azure-vote-back spec:   replicas: 1   selector:     matchLabels:       app: azure-vote-back   template:     metadata:       labels:         app: azure-vote-back     spec:       nodeSelector:         « beta.kubernetes.io/os »: linux       containers:       – name: azure-vote-back         image: redis         resources:           requests:             cpu: 100m             memory: 128Mi           limits:             cpu: 250m             memory: 256Mi         ports:         – containerPort: 6379           name: redis — apiVersion: v1 kind: Service metadata:   name: azure-vote-back spec:   ports:   – port: 6379   selector:     app: azure-vote-back — apiVersion: apps/v1 kind: Deployment metadata:   name: azure-vote-front spec:   replicas: 1   selector:     matchLabels:       app: azure-vote-front   template:     metadata:       labels:         app: azure-vote-front     spec:       nodeSelector:         « beta.kubernetes.io/os »: linux       containers:       – name: azure-vote-front         image: microsoft/azure-vote-front:v1         resources:           requests:             cpu: 100m             memory: 128Mi           limits:             cpu: 250m             memory: 256Mi         ports:         – containerPort: 80         env:         – name: REDIS           value: « azure-vote-back » — apiVersion: v1 kind: Service metadata:   name: azure-vote-front spec:   type: LoadBalancer   ports:   – port: 80   selector:     app: azure-vote-front   Execution Voici la commande à executer (dans le repertoire de votre fichier yaml) kubectl apply -f azure-vote.yaml Pour vérifier on va taper cette commande kubectl get service azure-vote-front –watch Un tpi tour via un browser sur http://40.71.233.76/ Tindin ! Personnellement je n’ai jamais monté un site web aussi rapidement ! Watch me L’idée maintenant c’est d’aller voir l’interface web de gestion d’AKS. En tapant la commande suivante dans un shell sur le portail web azure (aide) (ça va aussi créer un espace de stockage dédié au shell) ou depuis votre terminal : az aks browse –resource-group myResourceGroup –name myAKSCluster Ca ouvre un tunnel vers AKS et une page sur votre navigateur. Personnellement, j’ai direct 12 erreurs : Ce blog peut aider :https://mohamedradwan.com/2019/06/05/how-to-solve-forbidden-user-error-kubernetes-web-dashboard-for-kubernetes-clusters/ Pour ma part j’ai juste eu à taper cette commande : kubectl create clusterrolebinding kubernetes-dashboard -n kube-system –clusterrole=cluster-admin –serviceaccount=kube-system:kubernetes-dashboard Et bim ! Delete me Pour supprimer le cluster : az aks delete –resource-group TutorialResources –name myAKSCluster –no-wait ou plus brutal : az group delete –name TutorialResources Tarifs Pour l’ensemble des tutos précédents et celui ci, c’est a dire 2 VMs et tout le bardat qui vient avec, un AKS et qq tests, ca m’a couté : 7.18€ Je ne sais pas trop quoi en penser. 3 ou 4€ par jour c’est à la fois pas cher et cher aussi : – cher parce que j’ai concretement pas fait grand chose avec qq requêtes web… – pas cher car j’ai en qq minutes lancer une infra qui m’aurait prit des semaines avec de vrais serveurs. Je n’ai pas encore de notion de tarifs sur Azure. C’est vraiment obscure. L’expérience nous le dira et je ferai un retour la desssus quand ce sera possible. J’ai effacé tous les groupes de resources et ce qu’il contenait, je viens de repartir sur une base fraiche toute neuve, vierge de tout. EDIT : Bon Azure est une pompe a fric pour le simple développeur qui veut juste tester. Heureusement qu’il y a un trial, court, car il se termine aujourd’hui donc 14 jours il me semble. En regardant la projection sur le mois, j’arriverai à 276 €. Hors de question de payer ce montant la. Un jour peut être avec une app qui mérite…

Tuto AKS – mise en place

Dans cet article nous allons mettre en place AKS sur Azure en ligne de commande. AKS en ligne de commande : https://docs.microsoft.com/fr-fr/azure/aks/kubernetes-walkthrough Prérequis : avoir installer deux VMs sur azure (voir le tuto précédent) En avant Guingamp : az aks create –resource-group TutorialResources –name myAKSCluster –node-count 1 –enable-addons monitoring –generate-ssh-keys Cette commande va créer AKS sur un cluster nommé myAKSCluster avec une seule node et du monitoring. Ca prends qq minutes… La commande va normalement vous renvoyer du JSON avec toute la config installée : Json { « aadProfile »: null, « addonProfiles »: { « omsagent »: { « config »: { « logAnalyticsWorkspaceResourceID »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourcegroups/defaultresourcegroup-eus/providers/microsoft.operationalinsights/workspaces/defaultworkspace-eaeaae83-9dcd-405b-8f02-4e58e0e30bbb-eus » }, « enabled »: true } }, « agentPoolProfiles »: [ { « availabilityZones »: null, « count »: 1, « enableAutoScaling »: null, « enableNodePublicIp »: null, « maxCount »: null, « maxPods »: 110, « minCount »: null, « name »: « nodepool1 », « nodeTaints »: null, « orchestratorVersion »: « 1.14.8 », « osDiskSizeGb »: 100, « osType »: « Linux », « provisioningState »: « Succeeded », « scaleSetEvictionPolicy »: null, « scaleSetPriority »: null, « type »: « VirtualMachineScaleSets », « vmSize »: « Standard_DS2_v2 », « vnetSubnetId »: null } ], « apiServerAccessProfile »: null, « dnsPrefix »: « myAKSClust-TutorialResource-eaeaae », « enablePodSecurityPolicy »: null, « enableRbac »: true, « fqdn »: « myaksclust-tutorialresource-eaeaae-955218b3.hcp.eastus.azmk8s.io », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourcegroups/TutorialResources/providers/Microsoft.ContainerService/managedClusters/myAKSCluster », « identity »: null, « kubernetesVersion »: « 1.14.8 », « linuxProfile »: { « adminUsername »: « azureuser », « ssh »: { « publicKeys »: [ { « keyData »: « ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxi46MPyNjpH/kBnXxU5t4bPcWpeCrByvAH9p6uzM+IDda+NTrWHpEmUr1IVZS7CXku5lpl6v3WJjuK1E35DdB5s2ewB7VR6iYKHgruqduAeprMdUx34xeXxn7cc9/QC1b83Lw7k+oyYYYoIfYcy9q/beIlBco8Eidj6GxNRk74fHd3H5r99W0pqA4IfIFpksOb19iiO+pgiABgewmAQETldclajNjVuV6G3cVDdFILGUXjSA/Z1d1eWoqh00XbtyY7sl3LkLd6puHTm1Qt5UlcD4mZKpI2ggqWicHVLA2Eq2Fz7GE637CdYsqXXs5eDJUeBA8S+d2fas00zMB4Pyb » } ] } }, « location »: « eastus », « maxAgentPools »: 8, « name »: « myAKSCluster », « networkProfile »: { « dnsServiceIp »: « 10.0.0.10 », « dockerBridgeCidr »: « 172.17.0.1/16 », « loadBalancerProfile »: { « effectiveOutboundIps »: [ { « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/MC_TutorialResources_myAKSCluster_eastus/providers/Microsoft.Network/publicIPAddresses/449f34d6-68cb-49ad-aa08-825d6448e1d7 », « resourceGroup »: « MC_TutorialResources_myAKSCluster_eastus » } ], « managedOutboundIps »: { « count »: 1 }, « outboundIpPrefixes »: null, « outboundIps »: null }, « loadBalancerSku »: « Standard », « networkPlugin »: « kubenet », « networkPolicy »: null, « outboundType »: « loadBalancer », « podCidr »: « 10.244.0.0/16 », « serviceCidr »: « 10.0.0.0/16 » }, « nodeResourceGroup »: « MC_TutorialResources_myAKSCluster_eastus », « privateFqdn »: null, « provisioningState »: « Succeeded », « resourceGroup »: « TutorialResources », « servicePrincipalProfile »: { « clientId »: « f00bf5fa-37b4-42e5-9f2f-33ff3f32c672 », « secret »: null }, « tags »: null, « type »: « Microsoft.ContainerService/ManagedClusters », « windowsProfile »: null } AKS est maintenant installé dans le groupe de ressource « TutorialResources » Lors de la création d’un cluster AKS, un deuxième groupe de ressources est automatiquement créé pour stocker les ressources AKS. Pour ma part il s’appelle DefaultResourceGroup-EUS. Dedans on y trouve ceci : Le premier est un « espace de travail Log Analytics ». Le second est une « solution ».  Pour le moment je ne sais pas trop a quoi correspond ce dernier. Enfin, l’installation d’AKS a généré un troisieme groupe de ressources avec 5 éléments : Dans l’ordre affiché nous avons un équilibreur de charge un groupe de sécurité réseau une adresse IP publique une table de routage un réseau virtuel. Voilà, beaucoup d’élément on été automatiquement installé. C’est une configuration par défaut qu’il faudra bien sûr ajuster aux besoins.  Pour la suite on va avoir besoin de kubectl qui est le client de ligne de commande Kubernetes. Si vous avez DockerDesktop avec la case Kubernetes cochée, vous devriez déjà l’avoir. Sinon vous pouvez toujours l’obtenir avec cette commande : az aks install-cli Pour se connecter à notre cluster aks via kubectl : az aks get-credentials –resource-group TutorialResources –name myAKSCluster   réponse : Merged « myAKSCluster » as current context in C:\Users\Yann\.kube\config   Pour voir les nodes : kubectl get nodes On y est, Kubernetes est installé sur notre cluster et tourne avec une seule node. 

Azure CLI – tuto 2 VMs

Tuto pour apprendre avec Azure CLI à monter des VMs et ensuite utiliser AKS (prochain tuto). Prérequis : avoir un compte Azure (il en existe des gratuits avec 170€ de crédits) et Azure Cli installé sur sa machine. Azure cli : https://docs.microsoft.com/fr-fr/cli/azure/get-started-with-azure-cli?view=azure-cli-latest Création d’une VM 1 Pour tester azure cli, on va lui demander sa version az –version azure-cli 2.0.80 (…) On va maintenant se connecter sur Azure via cette commande az login Cela ouvre un browser pour se connecter au portail web. Après connextion, le terminal affiche les abonnements Azure Nous allons créer un groupe de ressources : az group create –name TutorialResources –location eastus Il n’est pas apparu sur le portail web d’Azure. Sans doute car je n’avais aucune ressources dedans pour le moment. Nous allons maintenant créer notre première Virtual Machine en ligne de commande : az vm create –resource-group TutorialResources ` –name TutorialVM1 ` –image UbuntuLTS ` –generate-ssh-keys ` –output json ` –admin-username yannvasseur ` –verbose Note : sous powershell une commande multi ligne se termine par ` (en bash c’est \ ) j’ai dû rajouter –admin-username yannvasseur ` à cette commande car on avait une erreur sinon. Il faut qq minutes pour créer une VM, voici ce que la commande nous retourne : { « fqdns »: «  », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Compute/virtualMachines/TutorialVM1 », « location »: « eastus », « macAddress »: « 00-0D-3A-8D-7D-07 », « powerState »: « VM running », « privateIpAddress »: « 10.0.0.4 », « publicIpAddress »: « 13.90.91.229 », « resourceGroup »: « TutorialResources », « zones »: «  » } Pour obtenir plus d’information sur cette VM : az vm show –name TutorialVM1 –resource-group TutorialResources Le listing que vous obtenez est plutot long, mais d’autant plus complet. Remarquez que l’on a pas de password pour l’administrateur. Json results : Si on se connecte sur le portail web Azure, on voit tout ce qui a été créé : Dans l’ordre affiché on a une machine virtuelle Standard DS1 v2 (1 processeurs virtuels, 3.5 Gio de mémoire) sous Linux (ubuntu 18.04), un disque de 30Go SSD premium, un groupe de sécurité réseau (un firewall), une adresse IP publique (13.90.91.229), une interface réseau et un réseau privé virtuel (10.0.0.0/16). L’emplacement est USA est. Tout ca en une ligne de commande ! VM2 On va maintenant en créer une deuxieme parce qu’on est foufou. Mais avant cela on va récupérer des infos sur notre premiere VM concernant notre subnet (sous réseau) afin que nos deux VMs soient sur le même réseau : az vm show –name TutorialVM1 ` –resource-group TutorialResources ` –query ‘networkProfile.networkInterfaces[].id’ ` –output tsv Résultat : /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/networkInterfaces/TutorialVM1VMNic Cette commande nous permet d’obtenir l’id de notre interface réseau VM1. A partir de cet id, on va demander a azure toutes les informations de cette interface réseau : az network nic show –ids /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/networkInterfaces/TutorialVM1VMNic info interface réseau On va devoir récupérer l’id de l’IP (et pour plus tard on aura peut etre besoin de l’id du sous réseau) az network nic show –ids /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/networkInterfaces/TutorialVM1VMNic ` –query ‘{IP:ipConfigurations[].publicIpAddress.id, Subnet:ipConfigurations[].subnet.id}’ ` -o json Voici le résultat, sous forme de donnée JSON : { « IP »: [ « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/publicIPAddresses/TutorialVM1PublicIP » ], « Subnet »: [ « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/virtualNetworks/TutorialVM1VNET/subnets/TutorialVM1Subnet » ] } Maintenant on va créer une deuxième VM avec cette commande az vm create –resource-group TutorialResources ` –name TutorialVM2 ` –image UbuntuLTS ` –generate-ssh-keys ` –subnet /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/virtualNetworks/TutorialVM1VNET/subnets/TutorialVM1Subnet ` –admin-username yannvasseur ` –output json ` –verbose Notez que l’on juste rajouté un sous réseau et renommer son nom. Voici le résultat : Use existing SSH public key file: C:\\Users\\Yann\\.ssh\\id_rsa.pub Accepted: vm_deploy_Ud4Y1LjR5olzzHxJhIQ1kNiWStjJCeBn (Microsoft.Resources/deployments) { « fqdns »: «  », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Compute/virtualMachines/TutorialVM2 », « location »: « eastus », « macAddress »: « 00-0D-3A-18-E6-A5 », « powerState »: « VM running », « privateIpAddress »: « 10.0.0.5 », « publicIpAddress »: « 40.117.142.145 », « resourceGroup »: « TutorialResources », « zones »: «  » } command ran in 103.297 seconds. Et voila notre 2ime VM est créée. Ce qui est vérifié sur le portail web : Nettoyage Si vou souhaitez tout effacer, c’est par ici : https://docs.microsoft.com/fr-fr/cli/azure/azure-cli-vm-tutorial?tutorial-step=7&view=azure-cli-latest

Kubernetes & AKS – Intro

Intro Kubernetes (communément appelé « K8S ») est un système open source qui vise à fournir une « plate-forme permettant d’automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d’application sur des clusters de serveurs ». Il fonctionne avec toute une série de technologies de conteneurisation, et est souvent utilisé avec Docker. Il a été conçu à l’origine par Google, puis offert à la Cloud Native Computing Foundation. (Wikipedia) AKS (Azure Kubernete Service) est un service Kubernetes sur Azure. Il permet d’automatiser le déploiement, la mise à l’échelle et le fonctionnement de conteneurs d’application entre des clusters d’hôtes. C’est un orchestrateur de conteneur. Cela signifie qu’il est en charge de monter des conteneurs suivant un plan que l’on fixe. Il peut par exemple automatiser la charge (monter des conteneurs supplémentaire), relancer un conteneur défaillant, prévoir une réduction ou une augmentation de charge (planification) et donc adapter des besoins suivant des critères (horraire, ponctuel, exceptionnel, CPU, Bandwidth…) https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ L’image ci dessous permet d’illustrer ce qu’est un cluster de conteneurs : Un cluster Kubernetes regroupe plusieurs hôtes Docker et les expose sous la forme d’un seul hôte Docker virtuel. Vous pouvez donc déployer plusieurs conteneurs sur le cluster et effectuer un scale-out d’un nombre illimité d’instances de conteneurs. Le cluster prend en charge tous les détails complexes de la gestion, comme la scalabilité, l’intégrité,etc. Structure et topologie Kubernetes dispose d’une structure basée sur un Master Node et des Nodes. Le Master Node contrôle les nodes. Ces dernières sont des machines virtuelles ou physique. Sur une node on peut retrouver un ou des Pods. Un namespace permet de segmenter des pods, volumes, secrets, configmap… On peut avoir deux namespaces (par exemple dev et staging) sur le même cluster. (là où d’habitude on travaillait avec des machines séparées sur une app monolithique) kubectl est l’application en ligne de commande permettant d’interragir avec Kubernetes. Il est possible d’utiliser Kubernetes sur votre machine locale avec Docker Desktop en cochant cet option : Il est donc possible de travailler localement et préparer ses fichier yaml pour AKS (dev, staging, prod) Pour cela il faut aussi préparer nos conteneurs et les déposer sur un registre (Docker Registry sur Azure) afin qu’ils puissent être utilisé par AKS. Ressources pour se former : Podcast Devapps.be Introduction à Kubernetes : https://www.youtube.com/watch?v=b5vJsYR-Vbo La doc microsoft : https://docs.microsoft.com/fr-fr/azure/aks/ Comprendre Kubernetes en 3 minutes : https://www.youtube.com/watch?v=uyiDNcSmwFw (perso j’ai rien compris…) Celle la est mieux https://www.youtube.com/watch?v=QJ4fODH6DXI xavki : https://www.youtube.com/watch?v=vFfngcRPj9M Web2Day 2017 : https://www.youtube.com/watch?v=zztKO0iRX_w&t=175s

Ocelot

Ocelot est un middleware pour .net core qui permet de créer une « gateway » (un point d’entrée) unique pour un ensemble de micro service. C’est une sorte de router. Par exemple, admetons que l’on est deux services Asp.Net Core (Orders, Customers) qui tournent respectivement sur : localhost:7001 localhost:7002 Chacun ayant un simple controler « racine » qui retourne n’importe quoi. Ils sont à ce stade joigniables uniquement via ces url. On veut maintenant qu’ils soient tous accesibles depuis localhost:7000 : localhost:7000/orders localhost:7000/customers Pour cela on va ajouter le middleware Ocelot https://ocelot.readthedocs.io/en/latest/introduction/bigpicture.html et le configurer avec un fichier de configuration suivant : { « ReRoutes »: [ { « DownstreamPathTemplate »: « /api/orders », « DownstreamScheme »: « http », « DownstreamHostAndPorts »: [ { « Host »: « localhost », « Port »: 7000 } ], « UpstreamPathTemplate »: « /orders », }, { « DownstreamPathTemplate »: « /api/customers », « DownstreamScheme »: « http », « DownstreamHostAndPorts »: [ { « Host »: « localhost », « Port »: 7000 } ], « UpstreamPathTemplate »: « /customers », }, ], « GlobalConfiguration »: { « BaseUrl »; « <http://localhost7000> » } } Et hope, on a nos deux services accessible depuis le même point d’entrée (gateway) localhost:7000 Plus de précision avec cette vidéo :