Utilisation de Knife et Chef sur le Cloud Ikoula

Dans l'article précédent nous avons appris comment installer et utiliser knife et son plugin cloudstack avec le cloud ikoula. Cette fois-ci nous allons passer à des choses plus sérieuses c'est à dire l'utilisation de knife et chef afin d'installer des applications et commencer a nous frotter avec ce qu'on appelle l'infrastructure as code au sein du cloud ikoula.

L'infrastructure as code c'est quoi ?

C'est une manière de décrire la configuration d'une machine, des programmes qui doivent être installés dessus, des utilisateurs autorisés a se connecter, son rôle au sein d'une plateforme, etc... Cette description qui sert lors de la création de la machine, comme de sa maintenance se fait généralement grâce a un langage spécifique(DSL ou domain specific language) ou encore grâce à l'utilisation d'un langage comme ruby (Puppet et surtout Chef.

L'outil Chef fait une utilisation intensive du concept des cookbooks. Un cookbook est un ensemble de recettes (recipes) qui permettent de décrire de manière simple mais puissante une installation, une mise à jour d'une application, d'un environnement complet de développement,etc...

Notre propos étant içi de vous mettre le pied à l'étrier, nous allons tout de suite passer a du concret ! Nous mettrons en place un environnement de travail et nous lancerons très vite notre première machine et verrons comme par magie Chef la configurer.

Comme lors de notre dernier article, nous utilisons une machine en ubuntu 13.10, a nouveau les installations et mises en place peuvent varier selon la distribution ou l'os que vous utilisez. Si vous rencontrez des difficultés n'hésitez pas à rentrer en contact avec nous !

Chef-solo, knife-solo et librarian-chef

Le plus souvent il faut déployer un serveur Chef et connecter les machines que l'on veut gérer sur ce serveur notamment grace à l'outil chef-client. Comme nous n'allons déployer que quelques machines nous utiliserons deux outils pour nous passer du serveur Chef :
chef-solo (qui remplace donc le serveur Chef) et knife-solo qui nous facilite l'utilisation de chef-solo. Afin de faciliter là encore la gestion des cookbooks (leur dépendances, leur récupération, etc...) nous allons utiliser librarian-chef.

Commençons par installer toutes les gems nécessaires et donc créer notre environnement de travail :

ikoula@ubuntu1310:~$ sudo gem install knife-solo librarian-chef


Nous allons ensuite initialiser notre repository local (qui va garder les cookbooks, et autres informations de configuration) grace à knife solo. A ce propos nous allons appeler notre repository LocalRepository.

ikoula@ubuntu1310:~$ knife solo init --no-berkshelf LocalRepository


Cette commande crée donc une arborescence spécifique pour knife-solo qu'on peut visualiser grace à la commande tree :

ikoula@ubuntu1310:~/$ sudo apt-get install tree
ikoula@ubuntu1310:~/$ cd LocalRepository
ikoula@ubuntu1310:~/LocalRepository$ tree
.
+-- Cheffile
+-- cookbooks
+-- data_bags
+-- environments
+-- nodes
+-- roles
+-- site-cookbooks

6 directories, 1 file


Installation d'un cookbook : nginx

Nous allons commencer par créer une instance, installer et démarrer un serveur nginx sur celle-ci. Pour cela il nous faut un cookbook. Nous pourrions créer notre propre cookbook, mais pour démarrer rapidement nous allons en utiliser un fourni à la communauté par la société qui produit Chef.

Le fichier Cheffile est utilisé par librarian-chef comme liste référence de cookbooks. En somme c'est la liste des livres dans notre librairie.
On va y placer les cookbooks qu'il nous faut, et librarian-chef traitera du reste(téléchargement, update, dépendances éventuelles, etc...). Donc notre premier cookbook sera celui qui traite de nginx.

A l'aide de votre éditeur favori modifier le fichier Cheffile et placez-y ces lignes :

site 'http://community.opscode.com/api/v1'

cookbook 'nginx', '>= 1.0.0'


Ensuite effectuez, toujours dans le répertoire LocalRepository la commande suivante :

ikoula@ubuntu1310:~/LocalRepository$ librarian-chef install


Après que librarian-chef ait terminé son travail, on retrouve dans le répertoire cookbooks, celui de nginx et d'autres qui lui sont nécessaires en termes de dépendances.

Ou l'on reparle de knife.rb

Lors du précedent article nous avions configuré un fichier knife.rb afin d'y placer nos informations de connexion au cloud Ikoula. Récupérez donc ce fichier et placez-le dans le répertoire LocalRepository, cela facilitera les choses. Nous allons ajouter également ces lignes à ce fichier pour indiquer que nous souhaitons utiliser la version "solo" de Chef, et ne pas utiliser un autre gestionnaire de cookbooks(berkshelf). C'est utile pour le déploiement en bootstrap et en une ligne de commande, mais ce n'est pas nécessaire dans l'absolu.

knife[:berkshelf] = false
knife[:solo] = true


Zones du Cloud Ikoula et Sécurité

Un choix important lors du déploiement d'instances dans le cloud Ikoula est celui de la zone de déploiement. Nous avons actuellement la possiblité de déployer sur 3 zones.

ikoula@ubuntu1310:~/LocalRepository$ knife cs zone list
Name                                              Network Type  Security Groups
Zone 1 France Advance Routing (Z01-R0-IKDC01-FR)  Advanced      false          
Zone 2 France Advance Routing (Z02-R0-IKDC01-FR)  Advanced      false          
Zone 3 France Direct Routing (Z03-R0-IKDC01-FR)   Basic         true   


Nous allons pour des raisons de simplicité choisir de déployer notre instance en zone 3. Cette zone se distingue des deux autres par deux points importants : les instances disposent d'une adresse ipv4 dite publique et leur accès est sécurisé par le concept des Security Groups.

Un Security Group vous est attribué par défaut (Default Security Group), pensez à le configurer pour que vos instances déployées au sein de ce Security Group soient accessibles depuis l’extérieur (par exemple depuis votre réseau uniquement), si vous ne le faites pas knife-solo ne pourra pas "bootstrapper" vos instances.

Afin de bien voir comment faire je vous engage à aller voir nos faqs à propos des Security Groups.

Et le fichier config ssh ?

La simplicité de déploiement des instances dans le cloud Ikoula, permet souvent de créer et détruire des machines virtuelles qui n'ont que quelques heures, voir quelques minutes d'existence. L'une des conséquences c'est que souvent l'on se retrouve avec des alertes ssh de connexion indiquant qu'une machine n'a plus la même clé.

Pour éviter ce type d'erreurs on peut ajouter à son fichier ~/.ssh/config les quelques lignes suivantes.
Attention bien entendu cela n'est à effectuer que dans un contexte bien précis, car ce faisant vous diminuez assez fortement la sécurité de vos connexions. Cela n'est toutefois que limité aux seules ips de la zone 3 du Cloud Ikoula.

Host 178.170.68.*
 StrictHostKeyChecking no
 UserKnownHostsFile /dev/null


Notez également que dans cette configuration il n'y a pas non plus de conservation de la clé initiale dans un fichier ~/.ssh/known_hosts, c'est utile pour eviter d'avoir à répondre yes lors de la connexion initiale.

Paire de clés !

Il nous manque un dernier élément pour faciliter nos configurations automatisées des instances que nous allons créer sur le cloud Ikoula. C'est la création de paire de clés. Cette paire de clés,créée et référencée simplement, composée d'une clé privée et d'une clé publique, permettra à l'instance démarrée d’être accessible en ssh sans fournir de mot de passe, mais en presentant notre clé privée. La configuration et l'installation de la clé publique d'une paire de clés se fait automatiquement au sein du cloud ikoula.

commençons par créer cette paire de clés grace à la commande knife suivante :

ikoula@ubuntu1310:~/LocalRepository$ knife cs keypair create MaPaireDeCles
Creating SSH Keypair: MaPaireDeCles
Fingerprint: d8:bc:49:0e:b0:0b:fa:14:aa:13:bb:dc:41:b7:1f:92
-----BEGIN RSA PRIVATE KEY-----
....
-----END RSA PRIVATE KEY-----
ikoula@ubuntu1310:~/LocalRepository$ knife cs keypair list
Name            Fingerprint                                    
MaPaireDeCles   d8:bc:49:0e:b0:0b:fa:14:aa:13:bb:dc:41:b7:1f:92


Voila une paire de clés a été créée. Enregistrez la partie privée dans le répertoire LocalRepository sous le nom de fichier MaPaireDeCles.pem(par exemple).

Tout est prêt ? on peut y aller maintenant ?

Tous les éléments sont maintenant réunis pour pouvoir lancer notre déploiement d'instance avec l'installation et la configuration (basique) de nginx.

Toujours dans le répertoire LocalRepository lancez cette commande :
ikoula@ubuntu1310:~/LocalRepository$ knife cs server create nginx001 \
--template "Debian 7 - Minimal - 64bits" \
--service "m1.small" \
--zone "Zone 3 France Direct Routing (Z03-R0-IKDC01-FR)" \
--run-list "recipe[nginx]" \
--no-public-ip \
--keypair MaPaireDeCles \
--identity-file MaPaireDeCles.pem \
--no-host-key-verify


Cette commande aura pour effet de déployer une instance de Debian 7, avec l'offre de calcul m1.small en Zone 3. knife va "bootstrapper" ensuite l'instance via une connexion ssh par clé. knife installera chef, chef-solo, notre librairie de cookbooks et enfin lancera l’exécution du cookbook nginx qui installera et démarrera le service nginx. Et après ?

Cette méthode permet de déployer rapidement des environnements avec le lancement d'un cookbook au déploiement. Vous trouverez ensuite dans le répertoire LocalRepository/nodes un fichier json au nom de la machine déployée, qui vous permettra de modifier sa configuration et par exemple d'ajouter d'autres cookbooks. Nous verrons ce point dans la troisième partie de cet série d'articles.


Ajouter un commentaire