FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierIT-Connect

Automatiser le processus de mise à jour Apt sur Debian

15 octobre 2021 à 10:00

I. Présentation

Dans ce tutoriel, nous allons voir comment automatiser le processus de mise à jour d'une machine Linux sous Debian ou Ubuntu. En effet, à partir d'un certain nombre d'instances de VM (ou de machines physiques), il est assez fastidieux de taper ne serait-ce qu'une fois par mois : "apt update && apt upgrade" sur toutes vos machines. L'objectif de cet article est de se la jouer fainéant, mais surtout futé en automatisant le processus.

"Je choisis une personne paresseuse pour un travail difficile, car une personne paresseuse va trouver un moyen facile de le faire." - Bill Gates 

II. Automatiser le processus de mise à jour avec un script bash

Nous allons créer un petit script bash pour réaliser notre automatisation. Afin de garder une trace de chaque exécution, je vais rediriger le contenu de stderr (en cas de retour d'une erreur lors de l'exécution du script) et stdout (en cas de succès).

Plus d'informations concernant la redirection des flux standard sous Linux.

Suivez les étapes ci-dessous, les commentaires sont là pour vous guider.

# Création du fichier
touch /home/user/script.sh 

# Edition du script
nano /home/user/script.sh
# Contenu du script "script.sh"
#!/bin/bash
echo ">>------------------------------------------------$(date)---------------------------------------------<<" >> /var/log/update_upgrade.log
echo ">>------------------errors------------------------------$(date)---------------errors------------------------------<<" >> /var/log/update_upgrade.err
export DEBIAN_FRONTEND=noninteractive
apt-get update && apt-get upgrade -y >> /var/log/update_upgrade.log 2>> /var/log/update_upgrade.err

# On donne les droits d'exécution sur le script
chmod u+x /home/user/script.sh 

# On édite la crontab 
crontab -e 

# Adaptez l'heure de la cron en fonction de l'heure à laquelle vous souhaitez faire votre test. 
06 17 * * * /home/user/script.sh

# Affichez les logs 
cat /var/log/update_upgrade.*

Je vais détailler quelques éléments du script ci-dessous :

- "DEBIAN_FRONTEND=noninteractive" : Nous allons activer ce mode par le biais de l'instanciation d'une variable DEBIAN_FRONTEND.  Utilisez ce mode lorsque vous n'avez besoin d'aucune interaction lors de l'installation ou de la mise à niveau du système via apt. Il accepte la réponse par défaut pour toutes les questions. Il peut envoyer un message d'erreur à l'utilisateur root, mais c'est tout. Une interface parfaite pour les installations automatiques. On peut utiliser ce mode dans des fichiers Dockerfile, des scripts shell, etc.

- ">> /var/log/update_upgrade.log" : Redirige la sortie standard du couple de commandes vers le fichier update_upgrade.log, afin d'avoir une trace de ce qu'il s'est passé.

- "2>> /var/log/update_upgrade.err" : Redirige la ou les erreurs en cas d'échec du couple de commandes vers le fichier update_upgrade.err. Normalement, ce fichier devrait toujours être vide. Le cas contraire indiquerait que vous avez un problème lors de l'exécution des deux commandes (il faudrait le cas échéant, déprogrammer la tâche cron, puis investiguer manuellement). Cas concret : si vous avez une coupure internet pile au moment du lancement du processus, apt vous renverra une erreur.

Il est à noter que les upgrades de tous les paquets se feront automatiquement sur Debian/Ubuntu, sauf les upgrades du noyau Linux, qui sont exclus par défaut, lorsque apt upgrade est automatisé. Pour faire ce genre de mise à jour, il faudrait manuellement taper la commande. 

Note 1 : Si au sein de votre parc informatique, vous avez un très grand nombre de machines Debian/Ubuntu (plus d'une centaine) par exemple, il serait peut-être judicieux de créer votre propre reposiotry local. Je vous laisse le soin de consulter ces deux articles si le sujet vous intéresse :

Ubuntu : comment créer son propre repository local ?  

Debian : comment créer son propre repository local ?

Note 2 : lors de la première exécution du script, il se peut que vous obteniez les messages (warnings) suivant :

cat /var/log/update_upgrade.err

Après quelques recherches, cette erreur intervient lors de la première exécution du script. Mais par la suite, vous ne devriez pas la rencontrer de nouveau.

En effet d'après ce que j'en ai déduit, le processus dpkg parent d'apt s'inquiète que la modification du mode frontend ait été changée, et nous le signale simplement. En aucun cas, ces messages qui pourraient s'apparenter à des "erreurs fatales" ne sont bloquants pour la mise à jour des dépôts distants et l'installation de nouveaux paquets, donc pas de stress ! 🙂

III. Automatiser le processus de suppression des paquets obsolètes  ?

Hum... Selon moi ce n'est pas une bonne idée, car certaines applications (anciennes ou non) peuvent reposer sur d'anciens packages. Je ne vous recommande pas d'effectuer cette automatisation au risque de perturber certains services de vos serveurs et d'occasionner un dysfonctionnement.

Selon moi, la commande "apt autoremove" doit être exécutée manuellement et avec une attention toute particulière, afin de bien évaluer l'impact de la suppression des paquets détectés comme obsolète/plus utile.

IV. Conclusion et idées d'optimisations

L'automatisation c'est génial ! Mais, gardez en tête qu'il faut de temps à autre jeter un œil au fichier de log, afin de vérifier que les automatisations fonctionnent comme vous le souhaitez.

Pour cela, je vous conseille de vous créer un fichier Excel ou équivalent avec la création d'un planning de tâche cron. C'est ce que j'utilise actuellement, et cela me permet de "prendre de la hauteur" sur l'ensemble de mes automatisations, et de ne pas être perdu parmi les nombreuses tâches cron qui s'exécute (à savoir des dizaines...).

Afin de ne pas vérifier tous les fichiers de logs apt un par un sur tous vos serveurs, il pourrait être judicieux d'implémenter un serveur RSYSLOG afin de centraliser la gestion de vos logs de mises à jour. Comme je suis sympa, je vous donne le morceau de configuration a ajouter dans la configuration rsyslog côté client (pas besoin de mettre quoi que ce soit dans la configuration côté serveur rsyslog).

Ajoutez ce bout de code à la fin du fichier /etc/rsyslog.conf de la machine qui transfert ses logs, et adaptez le en conséquence.

# ...
$ModLoad imfile
$InputFileName /var/log/update_upgrade.log
$InputFileTag tag_app_log:
$InputFileStateFile app_log1
$InputFileSeverity info
$InputFileFacility apt-update-upgrade
$InputRunFileMonitor
apt-update-upgrade @ip-du-serveur-rsyslog:514

# Si-vous utilisez TCP pour le transfert des logs au lieu d'UDP, veilliez à mettre deux @@ au lieu d'un.

A vous de jouer !

The post Automatiser le processus de mise à jour Apt sur Debian first appeared on IT-Connect.

Comment publier une image Dockerfile sur le référentiel Docker Hub ?

23 septembre 2021 à 10:00

I. Présentation

Aujourd'hui, nous allons voir comment publier une image Docker, par l'intermédiaire du repository officiel Docker Hub. Vous vous demandez surement dans quel but réaliser cette démarche ? Et bien, cela permettra à une tierce personne de récupérer facilement le container de votre projet, sans passer par la phase de "build", c'est-à-dire de construction de votre image. En effet, celle-ci sera utilisable par tout le monde, ou un cercle restreint de personne dans le cadre d'une publication de l'image en mode privé (non démontré dans cet article).

Pour ce tutoriel, je m'inspire d'un article déjà en ligne au sujet de Docker : comment conteneuriser une application web avec Docker ?

Sans plus attendre découvrons comment publier une image sur Docker Hub !

II. Premiers pas avec Docker Hub

Dans un premier temps, inscrivez-vous directement sur le site, c'est gratuit et ça se passe par ici : Docker Hub - Inscription

Ensuite, sur la page d'accueil, nous allons cliquer sur "Repository", puis "Create repository".

 

Un repository Docker Hub va accueillir une seule et unique image docker, que nous allons construire par l'intermédiaire d'un fichier Dockerfile. Nommez votre repository, et choisissez l'option "Public" avant de cliquer sur "Create". Pour ma part, le dépôt se nommera "mywebapp".

Une fois que cela est fait, vous allez obtenir la page suivante.

III. Publier une image sur Docker Hub

Nous laissons de côté notre navigateur pour maintenant utiliser le terminal d'un hôte équipé de Docker. Connectez-vous sur votre hôte docker et exécutez les commandes suivantes :

docker login
<entrez votre identifiant docker>
<entrez votre mot de passe docker>

Listez vos images :

docker images

Dans mon cas, je souhaite publier l'image "mywebapp" que j'ai créée par l'intermédiaire d'un Dockerfile (vu dans l'article précédent). Par la suite, j'assigne un label à mon image par l'intermédiaire de la commande docker tag, puis grâce à la commande docker push, je vais charger cette image sur mon repository Docker Hub "archidote/mywebapp". Ce qui donne les deux commandes suivantes :

docker tag mywebapp archidote/mywebapp
docker push archidote/mywebapp

Une fois l'upload terminé, on peut de nouveau lister les images Docker et l'on verra la présence de l'image "archidote/mywebapp", sur Docker Hub.

docker images

L'image a correctement été envoyée sur notre repository Docker Hub !

IV. Tester l'image hébergée sur Docker Hub

Afin de vérifier si l'image est réellement fonctionnelle, supprimez l'image "archidote/mywebapp" de votre banque d'images Docker ainsi que de votre banque de conteneurs à l'aide des commandes suivantes :

docker rmi <ids>

docker rm <ids>

Puis, une fois que cela est fait, je lance l'instanciation de mon container depuis l'image que j'ai envoyée précédemment sur Docker Hub.

docker run -d -p 8080:80 archidote/mywebapp
docker ps # Permet de vérifier si le conteneur est en cours d'exécution.

Pour vérifier le bon fonctionnement du conteneur, il ne me reste plus qu'à accéder à sa page Web via l'adresse suivante :

http://<adresse-ip>:8080

Voilà, nous venons de charger l'image d'un container Docker sur Docker Hub et ensuite nous avons vu comment déployer cette image Docker à partir du dépôt Docker Hub ! J'espère que ce tutoriel vous sera utile !

The post Comment publier une image Dockerfile sur le référentiel Docker Hub ? first appeared on IT-Connect.

Comment conteneuriser une application web avec Docker ?

15 septembre 2021 à 10:00

I. Présentation

Aujourd'hui, nous allons voir comment conteneuriser votre application web / site web avec Docker, par l'intermédiaire d'un exemple simple. Vous vous demandez surement dans quel but/objectif conteneuriser un projet ? Et bien cela permettra à une tierce personne de tester "On the fly" votre projet, en outrepassant une phase d'installation (de dépendances, etc.) qui peut s'avérer longue en fonction du type de solution. En effet, celle-ci sera intégrée directement dans l'image du conteneur Docker. Si vous souhaitez que quelqu'un puisse tester votre projet, c'est une bonne manière de lui simplifier le déploiement !

Si vous n'êtes pas très à l'aise avec Docker, je vous encourage à lire le cours suivant d'OpenClassrooms. La conteneurisation avec Docker est une technologie à part entière comme Git, vous ne pourrez pas saisir et comprendre tous les concepts et mécanismes en 1 heure... 🙂

En complément, je vous invite à consulter la ressource suivante si la technologie de conteneurisation est encore très floue pour vous : Principe des DockerFile.

II. Rédaction du fichier Dockerfile

Dans le cas présenté ci-dessous, je souhaite conteneuriser une page web que j'ai développée, permettant d'afficher un compte à rebours en fonction d'une date précise. Dans la pratique, ce n'est clairement pas la peine de conteneuriser cela, car le projet peut tourner facilement sur n'importe quel ordinateur en local disposant d'un navigateur web compatible avec JavaScript Internet Explorer. Mais, imaginez un plus gros projet digne de ce nom, requérant des outils comme PHP, NodeJS, Maven ou autre chose.

Le fait de conteneuriser son application (avec Docker ou autre) prend alors tout son sens, car cela évitera à la personne souhaitant tester l'application d'installer un environnement spécifique (long et fastidieux), si cela est simplement pour un vulgaire test.

Passons à la pratique... Ouvrez un terminal et saisissez les deux commandes suivantes pour créer le dossier "myWebApp" et le fichier "Dockerfile" à l'intérieur :

mkdir myWebApp
touch myWebApp/Dockerfile

Il est important de créer un dossier (à l'emplacement que vous souhaitez) et stocker le fichier DockerFile à l'intérieur. En fait, quand nous allons construire notre image, tout le contenu du dossier sera ajouté à notre image, d'où l'intérêt de "l'isoler".

Le fichier DockerFile va contenir toutes les instructions nécessaires à la fabrication de l'image de notre container. On va préciser l'image de base, ainsi que tous les paquets à installer et les données de notre site Web.

Editez le fichier avec votre éditeur de texte préféré, en insérant le contenu suivant : 

# Utilisation d'une image Ubuntu (par défaut la dernière en date) pour construire notre image docker file
FROM ubuntu 
# Mise à jour des repository distant du container, avant d'installer les paquets requis pour le projet
RUN apt update && apt upgrade -y
# Permet d'éviter d'avoir le bug concernant le choix de la timezone
RUN DEBIAN_FRONTEND="noninteractive" apt-get -y install tzdata 
# Installation des paquets requis pour le projet à savoir git et le service web apache2
RUN apt-get install -y -q git apache2 
# Le conteneur s'éxécutera en se basant sur le service apache2
ENTRYPOINT /usr/sbin/apache2ctl -D FOREGROUND 
# Renommage du fichier de base d'apache2 index.html vers index.html.old
RUN mv /var/www/html/index.html /var/www/html/index.html.old 
# Récupération de mon repository Git avec le mini projet
RUN git clone https://github.com/archidote/get-ready-simple-countdown-html-css-js 
# Copie des fichiers du mini projet web vers la racine de mon serveur web
RUN cd get-ready-simple-countdown-html-css-js && cp * /var/www/html/

Dès lors, enregistrez le fichier DockerFile, puis exécutez la commande suivante :

docker build .
# ou, si vous souhaitez nommer votre image Docker en "mywebapp" :
docker build -t mywebapp .

Une fois l'image construite, affichez les images présentes sur votre hôte Docker avec la commande suivante :

docker images 

Vous devriez voir la vôtre. Dans mon cas, elle est identifiée par l'ID suivant : 9e39...

III. Instanciation du container

L'image étant créée, il faut maintenant instancier un conteneur à partir de celle-ci. Utilisez la commande suivante :

docker run -d -p 8080:80 <id>
  • -d permets de lancer le conteneur en arrière plan (tâche de fond)
  • -p 8080:80 : permet d'exposer le port 8080 (de votre machine hôte Docker) vers le port 80 de votre container (là où est installé le service web, ainsi que le mini projet. C'est grâce à ce mécanisme, que vous allez pouvoir accéder à votre container depuis votre hôte Docker (via un navigateur web)

Vérifiez, que le conteneur est bien en cours d'exécution avec la commande suivante :

docker ps

Dès lors, ouvrez un navigateur et indiquez l'adresse IP de votre machine (hôte) ou localhost, en spécifiant le port "8080" que nous avons choisit précédemment.

Voilà ! L'application web en question, tourne sur le container que je viens de créer.

Si vous voulez interagir directement avec le shell du conteneur, pour éditer un fichier ou autres, entrez la commande suivante :

docker exec -it <id> bash

III. Conclusion

Le Dockerfile que je vous ai présenté peut vous servir de bonne base, pour la rédaction du vôtre. A vous d'adapter la configuration système et les dépendances requises en fonction des prérequis de votre application web :-).

The post Comment conteneuriser une application web avec Docker ? first appeared on IT-Connect.
❌