From 387c65a89a1a2dca54f5ec4a5c8ddcd746d0e2b3 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Thu, 25 Apr 2024 23:00:05 -0700 Subject: [PATCH 01/19] New translations 02-advanced.md (French) --- docs/books/learning_ansible/02-advanced.fr.md | 121 +++++++++--------- 1 file changed, 60 insertions(+), 61 deletions(-) diff --git a/docs/books/learning_ansible/02-advanced.fr.md b/docs/books/learning_ansible/02-advanced.fr.md index 0e5febf864..c4ca9358fe 100644 --- a/docs/books/learning_ansible/02-advanced.fr.md +++ b/docs/books/learning_ansible/02-advanced.fr.md @@ -10,15 +10,15 @@ Dans ce chapitre, vous allez approfondir vos connaissances sur Ansible. **Objectifs** : Dans ce chapitre, vous apprendrez à : -:heavy_check_mark: travailler avec des variables ; -:heavy_check_mark: utiliser des boucles ; -:heavy_check_mark: gérer les changements d'état et réagir en conséquence ; +:heavy_check_mark: travailler avec des variables ; +:heavy_check_mark: utiliser des boucles ; +:heavy_check_mark: gérer les changements d'état et réagir en conséquence ; :heavy_check_mark: gérer des tâches asynchrones. :checkered_flag: **ansible**, **module**, **playbook** -**Connaissances** : :star : :star : :star : -**Complexité** : :star : :star : +**Connaissances** : :star: :star: :star: +**Complexité** : :star: :star: **Temps de lecture** : 30 minutes @@ -49,7 +49,7 @@ Une variable peut être définie à différents endroits, comme dans un playbook Par exemple, à partir d'un playbook : -``` +```bash --- - hosts: apache1 vars: @@ -61,8 +61,8 @@ Par exemple, à partir d'un playbook : ou depuis la ligne de commande : -``` -$ ansible-playbook deploy-http.yml --extra-vars "service=httpd" +```bash +ansible-playbook deploy-http.yml --extra-vars "service=httpd" ``` Une fois définie, une variable peut être utilisée en l'appelant entre des accolades doubles : @@ -72,7 +72,7 @@ Une fois définie, une variable peut être utilisée en l'appelant entre des acc Par exemple : -``` +```bash - name: make sure apache is started ansible.builtin.systemd: name: "{{ service['rhel'] }}" @@ -85,7 +85,7 @@ Bien sûr, il est également possible d'accéder aux variables globales les fait Les variables peuvent être incluses dans un fichier externe au playbook, auquel cas ce fichier doit être défini dans le playbook avec la directive `vars_files` : -``` +```bash --- - hosts: apache1 vars_files: @@ -94,7 +94,7 @@ Les variables peuvent être incluses dans un fichier externe au playbook, auquel Le fichier `myvariables.yml` : -``` +```bash --- port_http: 80 ansible.builtin.systemd:: @@ -104,7 +104,7 @@ ansible.builtin.systemd:: Il peut également être ajouté dynamiquement avec l'utilisation du module `include_vars` : -``` +```bash - name: Include secrets. ansible.builtin.include_vars: file: vault.yml @@ -114,14 +114,14 @@ Il peut également être ajouté dynamiquement avec l'utilisation du module `inc Pour afficher une variable, vous devez activer le module `debug` comme suit : -``` +```bash - ansible.builtin.debug: var: service['debian'] ``` Vous pouvez également utiliser la variable à l'intérieur d'un texte : -``` +```bash - ansible.builtin.debug: msg: "Print a variable in a message : {{ service['debian'] }}" ``` @@ -132,7 +132,7 @@ Pour enregistrer le retour d'une tâche et pouvoir y accéder plus tard, vous de Utilisation d'une variable stockée : -``` +```bash - name: /home content shell: ls /home register: homes @@ -148,17 +148,17 @@ Utilisation d'une variable stockée : !!! note "Remarque" - La variable `homes.stdout_lines` est une liste de variables de type string, un moyen d'organiser des variables que nous n'avions pas encore rencontrées. + La variable `homes.stdout_lines` est une liste de variables de type 'string', un moyen d'organiser des variables que nous n'avions pas encore rencontrées. Les chaînes qui composent la variable stockée peuvent être accédées via la valeur `stdout` (qui vous permet de faire des choses comme `homes.stdout.find("core") != -1`), pour les exploiter en utilisant une boucle (voir `loop`) ou simplement par leurs indices tels que ce qui est illustré dans l'exemple précédent. -### Exercices +### Exercices : * Écrire un playbook `play-vars.yml` qui affiche le nom de la distribution de la cible avec sa version majeure, en utilisant des variables globales. * Écrivez un playbook en utilisant le dictionnaire suivant pour afficher les services qui seront installés : -``` +```bash service: web: name: apache @@ -182,9 +182,9 @@ Avec l'aide d'une boucle, vous pouvez itérer une tâche sur une liste, un hacha Plus d'informations peuvent être [trouvées ici](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html). -Exemple d'utilisation simple, création de 4 utilisateurs : +Exemple d'utilisation simple, création de quatre utilisateurs : -``` +```bash - name: add users user: name: "{{ item }}" @@ -201,7 +201,7 @@ Exemple d'utilisation simple, création de 4 utilisateurs : Bien sûr, une liste peut être définie dans un fichier externe : -``` +```bash users: - antoine - patrick @@ -211,7 +211,7 @@ users: et être utilisé dans la tâche comme ceci (après avoir inclus le fichier vars) : -``` +```bash - name: add users user: name: "{{ item }}" @@ -222,7 +222,7 @@ et être utilisé dans la tâche comme ceci (après avoir inclus le fichier vars Nous pouvons utiliser l'exemple vu lors de l'étude des variables stockées pour l'améliorer. Utilisation d'une variable stockée : -``` +```bash - name: /home content shell: ls /home register: homes @@ -241,7 +241,7 @@ Dans la boucle, il devient possible d'utiliser `item.key` qui correspond à la c Voyons cela à travers un exemple concret, montrant la gestion des utilisateurs du système : -``` +```bash --- - hosts: rocky8 become: true @@ -267,9 +267,9 @@ Voyons cela à travers un exemple concret, montrant la gestion des utilisateurs !!! note "Remarque" - Beaucoup de choses peuvent être faites avec les boucles. Vous découvrirez les possibilités qu'offrent les boucles au fur et à mesure que votre utilisation d'Ansible vous pousse à les utiliser de manière plus complexe. + Beaucoup d'applications peuvent être réalisées avec les boucles. Vous découvrirez les possibilités qu'offrent les boucles au fur et à mesure que votre utilisation d'Ansible vous pousse à les utiliser de manière plus complexe. -### Exercices +### Exercices : * Afficher le contenu de la variable `service` de l'exercice précédent en utilisant une boucle. @@ -291,9 +291,9 @@ L'instruction `when` est très utile dans de nombreux cas : ne pas effectuer cer !!! note "Remarque" - Derrière l'instruction `when` les variables n'ont pas besoin de doubles accolades (ce sont en fait des expressions Jinja2...). + Derrière l'instruction `when` les variables n'ont pas besoin de doubles accolades (ce sont en fait des expressions en Jinja2...). -``` +```bash - name: "Reboot only Debian servers" reboot: when: ansible_os_family == "Debian" @@ -301,7 +301,7 @@ L'instruction `when` est très utile dans de nombreux cas : ne pas effectuer cer Les conditions peuvent être regroupées avec des parenthèses : -``` +```bash - name: "Reboot only CentOS version 6 and Debian version 7" reboot: when: (ansible_distribution == "CentOS" and ansible_distribution_major_version == "6") or @@ -310,7 +310,7 @@ Les conditions peuvent être regroupées avec des parenthèses : Les conditions correspondant à un ET logique peuvent être fournies en tant que liste : -``` +```bash - name: "Reboot only CentOS version 6" reboot: when: @@ -320,7 +320,7 @@ Les conditions correspondant à un ET logique peuvent être fournies en tant que Vous pouvez tester la valeur d'un booléen et vérifier qu'il est vrai : -``` +```bash - name: check if directory exists stat: path: /home/ansible @@ -338,19 +338,19 @@ Vous pouvez tester la valeur d'un booléen et vérifier qu'il est vrai : Vous pouvez également tester que ce n'est pas vrai : -``` - when: - - file.stat.exists - - not file.stat.isdir +```bash +when: + - file.stat.exists + - not file.stat.isdir ``` Vous devrez probablement tester qu'une variable existe pour éviter les erreurs d'exécution : -``` - when: myboolean is defined and myboolean +```bash +when: myboolean is defined and myboolean ``` -### Exercices +### Exercices : * Afficher la valeur de `service.web` uniquement lorsque `type` est égal à `web`. @@ -360,15 +360,15 @@ Vous devrez probablement tester qu'une variable existe pour éviter les erreurs Vous trouverez de plus amples informations [ici](https://docs.ansible.com/ansible/latest/user_guide/playbooks_handlers.html). -Les handlers permettent de lancer des opérations, comme redémarrer un service, lorsque des changements se produisent. +Les 'handlers' permettent de lancer des opérations, comme redémarrer un service, lorsque des changements se produisent. -Un module, étant idempotent, un playbook peut détecter qu'il y a eu un changement significatif sur un système distant, et donc déclencher une opération en réaction à ce changement. Une notification est envoyée à la fin d'un bloc de tâches du playbook, et l'opération de réaction ne sera déclenchée qu'une seule fois même si plusieurs tâches envoient la même notification. +Un module, étant idempotent, un playbook peut détecter qu'il y a eu un changement significatif sur un système distant, et donc déclencher une opération en réaction à ce changement. Une notification est envoyée à la fin d'un bloc de tâches du playbook et l'opération de réaction ne sera déclenchée qu'une seule fois même si plusieurs tâches envoient la même notification. ![Handlers](images/handlers.png) Par exemple, plusieurs tâches peuvent indiquer que le service `httpd` doit être redémarré en raison d'un changement dans ses fichiers de configuration. Mais le service ne sera redémarré qu'une seule fois pour éviter de multiples démarrages inutiles. -``` +```bash - name: template configuration file template: src: template-site.j2 @@ -380,12 +380,12 @@ Par exemple, plusieurs tâches peuvent indiquer que le service `httpd` doit êtr Un handler est une sorte de tâche référencée par un nom global unique : -* Il est activé par un ou plusieurs notifiers. +* Il est activé par un ou plusieurs 'notifiers'. * Il ne commence pas immédiatement, mais attend que toutes les tâches soient terminées pour être exécuté. Exemple de handler : -``` +```bash handlers: - name: restart memcached @@ -401,7 +401,7 @@ handlers: Depuis la version 2.2 de l'Ansible, les handlers peuvent également écouter directement : -``` +```bash handlers: - name: restart memcached @@ -435,13 +435,13 @@ Cela peut causer des problèmes, en particulier : * si le temps d'exécution de la tâche est plus long que le délai de connexion SSH * si la connexion est interrompue pendant l'action (redémarrage du serveur par exemple) -Dans ce cas, vous devrez passer en mode asynchrone et spécifier un temps d'exécution maximum ainsi que la fréquence (par défaut 10) avec laquelle vous allez vérifier le statut de l'hôte. +Dans ce cas, vous devrez passer en mode asynchrone et spécifier un temps d'exécution maximum ainsi que la fréquence (par défaut 10s) avec laquelle vous allez vérifier le statut de l'hôte. En spécifiant une valeur de 0, Ansible exécute la tâche et continue sans se soucier du résultat. Voici un exemple utilisant des tâches asynchrones, qui vous permet de redémarrer un serveur et d'attendre que le port 22 soit à nouveau joignable : -``` +```bash # Wait 2s and launch the reboot - name: Reboot system shell: sleep 2 && shutdown -r now "Ansible reboot triggered" @@ -468,7 +468,7 @@ Vous pouvez également décider de lancer une tâche longue durée et de l'oubli * Écrire un playbook `play-vars.yml` qui affiche le nom de la distribution de la cible avec sa version majeure, en utilisant des variables globales. -``` +```bash --- - hosts: ansible_clients @@ -479,7 +479,7 @@ Vous pouvez également décider de lancer une tâche longue durée et de l'oubli msg: "The distribution is {{ ansible_distribution }} version {{ ansible_distribution_major_version }}" ``` -``` +```bash $ ansible-playbook play-vars.yml PLAY [ansible_clients] ********************************************************************************* @@ -499,7 +499,7 @@ PLAY RECAP ********************************************************************* * Écrire un playbook en utilisant le dictionnaire suivant pour afficher les services qui seront installés : -``` +```bash service: web: name: apache @@ -511,7 +511,7 @@ service: Le type par défaut doit être "web". -``` +```bash --- - hosts: ansible_clients vars: @@ -531,7 +531,7 @@ Le type par défaut doit être "web". msg: "The {{ service[type]['name'] }} will be installed with the packages {{ service[type].rpm }}" ``` -``` +```bash $ ansible-playbook display-dict.yml PLAY [ansible_clients] ********************************************************************************* @@ -551,7 +551,7 @@ PLAY RECAP ********************************************************************* * Remplacer la valeur de la variable `type` en utilisant la ligne de commande : -``` +```bash ansible-playbook --extra-vars "type=db" display-dict.yml PLAY [ansible_clients] ********************************************************************************* @@ -570,7 +570,7 @@ PLAY RECAP ********************************************************************* * Externaliser les variables dans un fichier `vars.yml` -``` +```bash type: web service: web: @@ -581,7 +581,7 @@ service: rpm: mariadb-server ``` -``` +```bash --- - hosts: ansible_clients vars_files: @@ -594,7 +594,6 @@ service: msg: "The {{ service[type]['name'] }} will be installed with the packages {{ service[type].rpm }}" ``` - * Afficher le contenu de la variable `service` de l'exercice précédent en utilisant une boucle. !!! note "Remarque" @@ -611,7 +610,7 @@ service: Avec `dict2items` : -``` +```bash --- - hosts: ansible_clients vars_files: @@ -625,7 +624,7 @@ Avec `dict2items` : loop: "{{ service | dict2items }}" ``` -``` +```bash $ ansible-playbook display-dict.yml PLAY [ansible_clients] ********************************************************************************* @@ -648,7 +647,7 @@ PLAY RECAP ********************************************************************* Avec `list` : -``` +```bash --- - hosts: ansible_clients vars_files: @@ -663,7 +662,7 @@ Avec `list` : ~ ``` -``` +```bash $ ansible-playbook display-dict.yml PLAY [ansible_clients] ********************************************************************************* @@ -685,7 +684,7 @@ PLAY RECAP ********************************************************************* * Afficher la valeur de `service.web` uniquement lorsque `type` équivaut à `web`. -``` +```bash --- - hosts: ansible_clients vars_files: @@ -705,7 +704,7 @@ PLAY RECAP ********************************************************************* when: type == "db" ``` -``` +```bash $ ansible-playbook display-dict.yml PLAY [ansible_clients] ********************************************************************************* From 14b57a95f7643021e0073b2267ba7ca11d40e37c Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Thu, 25 Apr 2024 23:00:06 -0700 Subject: [PATCH 02/19] New translations 03-working-with-files.md (French) --- .../03-working-with-files.fr.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/books/learning_ansible/03-working-with-files.fr.md b/docs/books/learning_ansible/03-working-with-files.fr.md index ceb057795e..70dfa8e3be 100644 --- a/docs/books/learning_ansible/03-working-with-files.fr.md +++ b/docs/books/learning_ansible/03-working-with-files.fr.md @@ -10,13 +10,13 @@ Dans ce chapitre, vous apprendrez à gérer des fichiers avec Ansible. **Objectifs** : Dans ce chapitre, vous apprendrez à : -:heavy_check_mark: modifier le contenu d'un fichier ; -:heavy_check_mark: transmettre des fichiers vers des serveurs cibles ; +:heavy_check_mark: modifier le contenu d'un fichier ; +:heavy_check_mark: transmettre des fichiers vers des serveurs cibles ; :heavy_check_mark: télécharger des fichiers à partir de serveurs distants. :checkered_flag: **ansible**, **module**, **fichiers** -**Connaissances** : :star: :star: +**Connaissances** : :star: :star: **Complexité** : :star: **Temps de lecture :** 23 minutes @@ -41,7 +41,7 @@ Le module nécessite : Exemple d'utilisation : -``` +```bash - name: change value on inifile community.general.ini_file: dest: /path/to/file.ini @@ -62,7 +62,7 @@ Dans ce cas, la ligne à modifier sera identifiée en utilisant regexp. Par exemple, pour s'assurer que la ligne qui commence par `SELINUX=` dans le fichier `/etc/selinux/config` contient bien la valeur `enforcing` : -``` +```bash - ansible.builtin.lineinfile: path: /etc/selinux/config regexp: '^SELINUX=' @@ -79,7 +79,7 @@ Pour copier un fichier à partir du serveur Ansible vers un ou plusieurs hôtes, L'exemple suivant illustre la copie du fichier `myflile.conf` d'un endroit à un autre : -``` +```bash - ansible.builtin.copy: src: /data/ansible/sources/myfile.conf dest: /etc/myfile.conf @@ -98,7 +98,7 @@ Pour copier un fichier à partir d'un serveur distant vers le serveur local, il Ce module effectue l'opération inverse du module `copy` : -``` +```bash - ansible.builtin.fetch: src: /etc/myfile.conf dest: /data/ansible/backup/myfile-{{ inventory_hostname }}.conf @@ -107,7 +107,7 @@ Ce module effectue l'opération inverse du module `copy` : ## Module `template` -Ansible et son module `template` utilisent le système de modèles **Jinja2** (http://jinja.pocoo.org/docs/) pour générer des fichiers dans la machine cible. +Ansible et son module `template` utilisent le système de modèles **Jinja2** () pour générer des fichiers dans la machine cible. !!! note "Remarque" @@ -115,7 +115,7 @@ Ansible et son module `template` utilisent le système de modèles **Jinja2** (h Par exemple : -``` +```bash - ansible.builtin.template: src: /data/ansible/templates/monfichier.j2 dest: /etc/myfile.conf @@ -126,7 +126,7 @@ Par exemple : Il est possible d'ajouter une étape de validation si le service ciblé le permet (par exemple avec apache en utilisant la commande `apachectl -t`) : -``` +```bash - template: src: /data/ansible/templates/vhost.j2 dest: /etc/httpd/sites-available/vhost.conf @@ -140,7 +140,7 @@ Il est possible d'ajouter une étape de validation si le service ciblé le perme Pour tranférer des fichiers à partir d'un site web ou ftp vers un ou plusieurs hôtes, vous pouvez utiliser le module `get_url` : -``` +```bash - get_url: url: http://site.com/archive.zip dest: /tmp/archive.zip From 341e889fa96dede5cad8b005e0c72595b14f09b9 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Fri, 26 Apr 2024 03:31:07 -0700 Subject: [PATCH 03/19] New translations 05-deployments.md (French) --- .../learning_ansible/05-deployments.fr.md | 124 +++++++++--------- 1 file changed, 61 insertions(+), 63 deletions(-) diff --git a/docs/books/learning_ansible/05-deployments.fr.md b/docs/books/learning_ansible/05-deployments.fr.md index 03ad7f18c1..9b7a56b687 100644 --- a/docs/books/learning_ansible/05-deployments.fr.md +++ b/docs/books/learning_ansible/05-deployments.fr.md @@ -10,16 +10,16 @@ Dans ce chapitre vous allez apprendre le déploiement d'applications en utilisan **Objectifs** : Dans ce chapitre, vous apprendrez : -:heavy_check_mark: Implémentation d'Ansistrano ; -:heavy_check_mark: Configuration d'Ansistrano ; -:heavy_check_mark: Utilisation de répertoires et de fichiers partagés entre des versions déployées ; -:heavy_check_mark: Déploiement de différentes versions d'un site à partir de git ; +:heavy_check_mark: Implémentation d'Ansistrano ; +:heavy_check_mark: Configuration d'Ansistrano ; +:heavy_check_mark: Utilisation de répertoires et de fichiers partagés entre des versions déployées ; +:heavy_check_mark: Déploiement de différentes versions d'un site à partir de git ; :heavy_check_mark: Rétrospective entre différentes étapes de déploiement. :checkered_flag: **ansible**, **ansistrano**, **rôles**, **déploiements** -**Connaissances**: :star: :star: -**Complexité**: :star: :star: :star: +**Connaissances** : :star: :star: +**Complexité** : :star: :star: :star: **Temps de lecture** : 40 minutes @@ -51,7 +51,7 @@ Ansistrano déploie des applications en suivant les 5 étapes suivantes : Le squelete d'un déploiement en utilisant Ansistrano se décrit comme suit : -``` +```bash /var/www/site/ ├── current -> ./releases/20210718100000Z ├── releases @@ -83,7 +83,7 @@ Le serveur géré : Pour une meilleure efficacité nous utiliserons le rôle `geerlingguy.apache` pour configurer le serveur : -``` +```bash $ ansible-galaxy role install geerlingguy.apache Starting galaxy role install process - downloading role 'apache', owned by geerlingguy @@ -94,7 +94,7 @@ Starting galaxy role install process Nous aurons probablement besoin d'accéder à certaines règles du pare-feu, ainsi nous installerons la collection `ansible.posix` pour utiliser le module `firewalld` : -``` +```bash $ ansible-galaxy collection install ansible.posix Starting galaxy collection install process Process install dependency map @@ -125,7 +125,7 @@ Considérations techniques : Le playbook pour configurer le serveur : `playbook-config-server.yml` -``` +```bash --- - hosts: ansible_clients become: yes @@ -136,27 +136,27 @@ Le playbook pour configurer le serveur : `playbook-config-server.yml` DirectoryIndex index.php index.htm apache_vhosts: - servername: "website" - documentroot: "{{ dest }}current/html" + documentroot: "{{ dest }}current/html" tasks: - name: create directory for website file: - path: /var/www/site/ - state: directory - mode: 0755 + path: /var/www/site/ + state: directory + mode: 0755 - name: install git package: - name: git - state: latest + name: git + state: latest - name: permit traffic in default zone for http service ansible.posix.firewalld: - service: http - permanent: yes - state: enabled - immediate: yes + service: http + permanent: yes + state: enabled + immediate: yes roles: - { role: geerlingguy.apache } @@ -164,13 +164,13 @@ Le playbook pour configurer le serveur : `playbook-config-server.yml` Pour appliquer le playbook au serveur : -``` -$ ansible-playbook playbook-config-server.yml +```bash +ansible-playbook playbook-config-server.yml ``` Notez l'exécution des tâches suivantes : -``` +```bash TASK [geerlingguy.apache : Ensure Apache is installed on RHEL.] **************** TASK [geerlingguy.apache : Configure Apache.] ********************************** TASK [geerlingguy.apache : Add apache vhosts configuration.] ******************* @@ -183,7 +183,7 @@ Le rôle `geerlingguy.apache` simplifie la tâche en prenant en charge l'install Vous pouvez vérifier le résultat en utilisant `curl` : -``` +```bash $ curl -I http://192.168.1.11 HTTP/1.1 404 Not Found Date: Mon, 05 Jul 2021 23:30:02 GMT @@ -201,7 +201,7 @@ Maintenant que notre serveur est opérationel, nous sommes en mesure de déploye Pour cela nous utiliserons le rôle `ansistrano.deploy` dans un deuxième playbook dédié au déploiement d'application (pour une meilleure lisibilité). -``` +```bash $ ansible-galaxy role install ansistrano.deploy Starting galaxy role install process - downloading role 'deploy', owned by ansistrano @@ -215,7 +215,7 @@ Les sources du logiciel se trouvent dans le dépôt de [github](https://github.c Nous allons créer un playbook `playbook-deploy.yml` pour gérer notre déploiement : -``` +```bash --- - hosts: ansible_clients become: yes @@ -230,7 +230,7 @@ Nous allons créer un playbook `playbook-deploy.yml` pour gérer notre déploiem - { role: ansistrano.deploy } ``` -``` +```bash $ ansible-playbook playbook-deploy.yml PLAY [ansible_clients] ********************************************************* @@ -257,13 +257,13 @@ TASK [ansistrano.deploy : ANSISTRANO | Change softlink to new release] TASK [ansistrano.deploy : ANSISTRANO | Clean up releases] PLAY RECAP ******************************************************************************************************************************************************************************************************** -192.168.1.11 : ok=25 changed=8 unreachable=0 failed=0 skipped=14 rescued=0 ignored=0 +192.168.1.11 : ok=25 changed=8 unreachable=0 failed=0 skipped=14 rescued=0 ignored=0 ``` Tout cela avec seulement onze lignes de code ! -``` +```html $ curl http://192.168.1.11 @@ -281,7 +281,7 @@ Vous pouvez maintenant vous connecter sur la machine client en utilisant ssh. * Créer une arborescence `tree` dans le répertoire `/var/www/site/` : -``` +```bash $ tree /var/www/site/ /var/www/site ├── current -> ./releases/20210722155312Z @@ -289,7 +289,7 @@ $ tree /var/www/site/ │   └── 20210722155312Z │   ├── REVISION │   └── html -│   └── index.htm +│   └── index.htm ├── repo │   └── html │   └── index.htm @@ -304,7 +304,7 @@ Notez s'il vous plait : * À partir du serveur Ansible relancez le déploiement **3** fois et vérifiez le résultat sur le serveur client. -``` +```bash $ tree /var/www/site/ var/www/site ├── current -> ./releases/20210722160048Z @@ -324,7 +324,7 @@ var/www/site │   └── 20210722160048Z │   ├── REVISION │   └── html -│   └── index.htm +│   └── index.htm ├── repo │   └── html │   └── index.htm @@ -342,7 +342,7 @@ La variable `ansistrano_keep_releases` indique le nombre de versions à conserve * En utilisant la variable `ansistrano_keep_releases`, conserver seulement 3 versions du projet. Vérifier le résultat. -``` +```bash --- - hosts: ansible_clients become: yes @@ -358,14 +358,14 @@ La variable `ansistrano_keep_releases` indique le nombre de versions à conserve - { role: ansistrano.deploy } ``` -``` +```bash --- $ ansible-playbook -i hosts playbook-deploy.yml ``` Sur la machine client : -``` +```bash $ tree /var/www/site/ /var/www/site ├── current -> ./releases/20210722160318Z @@ -381,7 +381,7 @@ $ tree /var/www/site/ │   └── 20210722160318Z │   ├── REVISION │   └── html -│   └── index.htm +│   └── index.htm ├── repo │   └── html │   └── index.htm @@ -390,8 +390,7 @@ $ tree /var/www/site/ ### Utilisation des variables shared_paths et shared_files - -``` +```bash --- - hosts: ansible_clients become: yes @@ -414,13 +413,13 @@ $ tree /var/www/site/ Créer le fichier `logs` dans le répertoire `shared` sur la machine client : -``` +```bash sudo touch /var/www/site/shared/logs ``` Ensuite relancez le playbook : -``` +```bash TASK [ansistrano.deploy : ANSISTRANO | Ensure shared paths targets are absent] ******************************************************* ok: [192.168.10.11] => (item=img) ok: [192.168.10.11] => (item=css) @@ -434,7 +433,7 @@ changed: [192.168.10.11] => (item=logs) Sur la machine client : -``` +```bash $ tree -F /var/www/site/ /var/www/site/ ├── current -> ./releases/20210722160631Z/ @@ -487,7 +486,7 @@ N'oubliez pas de modifier la configuration de Apache pour prendre en compte ce c Modifier le playbook pour la configuration du serveur `playbook-config-server.yml` -``` +```bash --- - hosts: ansible_clients become: yes @@ -498,20 +497,20 @@ Modifier le playbook pour la configuration du serveur `playbook-config-server.ym DirectoryIndex index.php index.htm apache_vhosts: - servername: "website" - documentroot: "{{ dest }}current/" # <1> + documentroot: "{{ dest }}current/" # <1> tasks: - name: create directory for website file: - path: /var/www/site/ - state: directory - mode: 0755 + path: /var/www/site/ + state: directory + mode: 0755 - name: install git package: - name: git - state: latest + name: git + state: latest roles: - { role: geerlingguy.apache } @@ -521,7 +520,7 @@ Modifier le playbook pour la configuration du serveur `playbook-config-server.ym Modifier le playbook de déploiement `playbook-deploy.yml` -``` +```bash --- - hosts: ansible_clients become: yes @@ -549,7 +548,7 @@ Modifier le playbook de déploiement `playbook-deploy.yml` * Vérifier le résultat sur la machine client : -``` +```bash $ tree -F /var/www/site/ /var/www/site/ ├── current -> ./releases/20210722161542Z/ @@ -588,7 +587,7 @@ La variable `ansistrano_git_branch` pour indiquer une `branch`e ou bien un `tag` * Deployer la branche `releases/v1.1.0` : -``` +```bash --- - hosts: ansible_clients become: yes @@ -615,7 +614,7 @@ La variable `ansistrano_git_branch` pour indiquer une `branch`e ou bien un `tag` Pendant le déploiement vous pouvez suivre les modifications en actualisant votre navigateur. -``` +```html $ curl http://192.168.1.11 @@ -629,7 +628,7 @@ $ curl http://192.168.1.11 * Deployer le tag `v2.0.0` : -``` +```bash --- - hosts: ansible_clients become: yes @@ -652,7 +651,7 @@ $ curl http://192.168.1.11 - { role: ansistrano.deploy } ``` -``` +```html $ curl http://192.168.1.11 @@ -685,8 +684,7 @@ Un playbook peut être inclus par l'intermédiaire de variables prévues dans ce * Un simple exemple : envoyer un courriel (ou tout ce que vous voulez, comme une notification Slack) en début de déploiement : - -``` +```bash --- - hosts: ansible_clients become: yes @@ -712,7 +710,7 @@ Un playbook peut être inclus par l'intermédiaire de variables prévues dans ce Créer le fichier `deploy/before-setup-tasks.yml` : -``` +```bash --- - name: Send a mail mail: @@ -720,7 +718,7 @@ Créer le fichier `deploy/before-setup-tasks.yml` : delegate_to: localhost ``` -``` +```bash TASK [ansistrano.deploy : include] ************************************************************************************* included: /home/ansible/deploy/before-setup-tasks.yml for 192.168.10.11 @@ -728,7 +726,7 @@ TASK [ansistrano.deploy : Send a mail] ***************************************** ok: [192.168.10.11 -> localhost] ``` -``` +```bash [root] # mailx Heirloom Mail version 12.5 7/5/10. ? affiche une page d'aide. "/var/spool/mail/root": 1 message 1 new @@ -737,7 +735,7 @@ Heirloom Mail version 12.5 7/5/10. ? affiche une page d'aide. * Vous devrez probablement relancer certains services en fin de déploiement, pour mettre à jour les caches, par exemple. Relancer Apache en fin de déploiement : -``` +```bash --- - hosts: ansible_clients become: yes @@ -764,7 +762,7 @@ Heirloom Mail version 12.5 7/5/10. ? affiche une page d'aide. Créer le fichier `deploy/after-symlink-tasks.yml` : -``` +```bash --- - name: restart apache systemd: @@ -772,7 +770,7 @@ Créer le fichier `deploy/after-symlink-tasks.yml` : state: restarted ``` -``` +```bash TASK [ansistrano.deploy : include] ************************************************************************************* included: /home/ansible/deploy/after-symlink-tasks.yml for 192.168.10.11 From 2d99d96f8bad65c4c1119c84317205c7e8fd31b3 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Fri, 26 Apr 2024 03:31:08 -0700 Subject: [PATCH 04/19] New translations 06-large-scale-infrastructure.md (French) --- .../06-large-scale-infrastructure.fr.md | 32 +++++++++---------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/docs/books/learning_ansible/06-large-scale-infrastructure.fr.md b/docs/books/learning_ansible/06-large-scale-infrastructure.fr.md index a56ea9f90e..351fd7063b 100644 --- a/docs/books/learning_ansible/06-large-scale-infrastructure.fr.md +++ b/docs/books/learning_ansible/06-large-scale-infrastructure.fr.md @@ -10,12 +10,12 @@ Dans ce chapitre vous allez apprendre à échelonner votre système de gestion d **Objectifs** : Dans ce chapitre, vous apprendrez à : -:heavy_check_mark: Organiser votre code pour gérer une grande infrastructure ; +:heavy_check_mark: Organiser votre code pour gérer une grande infrastructure ; :heavy_check_mark: Appliquer une partie ou le tout de votre gestionnaire de configuration à un groupe de nœuds ; :checkered_flag: **ansible**, **config management**, **scale** -**Connaissances** : :star: :star: :star: +**Connaissances** : :star: :star: :star: **Complexité** : :star: :star: :star: :star: **Temps de lecture** : 31 minutes @@ -52,7 +52,7 @@ Nous n'en avons pas encore parlé jusqu'à maintenant, mais il faut savoir qu'An La documentation d'Ansible suggère d'organiser notre code comme suit : -``` +```bash inventories/ production/ hosts # inventory file for production servers @@ -82,7 +82,7 @@ L'utilisation de balises d'Ansible vous permet d'exécuter ou ignorer partiellem Par exemple, modifions notre tâche de création d'utilisateur : -``` +```bash - name: add users user: name: "{{ item }}" @@ -98,7 +98,7 @@ Par exemple, modifions notre tâche de création d'utilisateur : Vous pouvez maintenant exécuter seulement les tâches indiquées par la balise `users` en utilisant l'option de `ansible-playbook` `--tags` : -``` +```bash ansible-playbook -i inventories/production/hosts --tags users site.yml ``` @@ -110,7 +110,7 @@ Nous allons nous concentrer sur une proposition d'organisation des fichiers et r Le fichier `site.yml` sera notre point de départ. Ce fichier est en quelque sorte le chef d'orchestre du système CMS en intégrant les rôles nécessaires pour les nœuds de destination si besoin est : -``` +```bash --- - name: "Config Management for {{ target }}" hosts: "{{ target }}" @@ -126,7 +126,7 @@ Bien sûr, ces rôles doivent être enregistrés dans le répertoire `roles` au Les variables globales peuvent être gérées dans un fichier `vars/global_vars.yml`, même si il serait possible de les enregistrer dans le fichier `inventories/production/group_vars/all.yml` -``` +```bash --- - name: "Config Management for {{ target }}" hosts: "{{ target }}" @@ -141,7 +141,7 @@ Les variables globales peuvent être gérées dans un fichier `vars/global_vars. On peut aussi garder la possibilité de déactiver une fonctionnalité. Ainsi nous inclurons les rôles avec une condition et une valeur par défaut comme suit : -``` +```bash --- - name: "Config Management for {{ target }}" hosts: "{{ target }}" @@ -160,8 +160,7 @@ On peut aussi garder la possibilité de déactiver une fonctionnalité. Ainsi no N'oubliez pas d'utiliser les balises : - -``` +```bash - name: "Config Management for {{ target }}" hosts: "{{ target }}" vars_files: @@ -183,7 +182,7 @@ N'oubliez pas d'utiliser les balises : Vous devriez obtenir quelque chose de similaire à ce qui suit : -``` +```bash $ tree cms cms ├── inventories @@ -218,7 +217,7 @@ cms Lançons le playbook pour éxécuter quelques tests : -``` +```bash $ ansible-playbook -i inventories/production/hosts -e "target=client1" site.yml PLAY [Config Management for client1] **************************************************************************** @@ -242,14 +241,13 @@ Comme vous pouvez le constater, par défaut, seulement les tâches du rôle `fun Activons dans l'inventaire `functionality2` pour notre nœud de destination et réexécutons le playbook : -``` +```bash $ vim inventories/production/host_vars/client1.yml --- enable_functionality2: true ``` - -``` +```bash $ ansible-playbook -i inventories/production/hosts -e "target=client1" site.yml PLAY [Config Management for client1] **************************************************************************** @@ -273,7 +271,7 @@ client1 : ok=3 changed=0 unreachable=0 failed=0 s Essayons de d'appliquer uniquement `functionality2` : -``` +```bash $ ansible-playbook -i inventories/production/hosts -e "target=client1" --tags functionality2 site.yml PLAY [Config Management for client1] **************************************************************************** @@ -292,7 +290,7 @@ client1 : ok=2 changed=0 unreachable=0 failed=0 s Lançons l'inventaire complet : -``` +```bash $ ansible-playbook -i inventories/production/hosts -e "target=plateform" site.yml PLAY [Config Management for plateform] ************************************************************************** From 5f93174092e98daffb01bcfc78e6efbd74d2cde3 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Fri, 26 Apr 2024 03:31:09 -0700 Subject: [PATCH 05/19] New translations 07-working-with-filters.md (French) --- .../07-working-with-filters.fr.md | 82 +++++++++---------- 1 file changed, 40 insertions(+), 42 deletions(-) diff --git a/docs/books/learning_ansible/07-working-with-filters.fr.md b/docs/books/learning_ansible/07-working-with-filters.fr.md index fe2b55eed6..d605de1267 100644 --- a/docs/books/learning_ansible/07-working-with-filters.fr.md +++ b/docs/books/learning_ansible/07-working-with-filters.fr.md @@ -17,8 +17,7 @@ Dans ce chapitre vous allez apprendre comment transformer les données grâce au :checkered_flag: **ansible**, **jinja**, **filtres** -**Compétences** : :star: :star: :star: -**Difficulté** : :star: :star: :star: :star: +**Compétences** : :star: :star: :star: **Difficulté** : :star: :star: :star: :star: **Temps de lecture : **23 minutes @@ -34,7 +33,7 @@ Ces filtres, écrits en Python, nous permettent de manipuler et de transformer n Tout au long de ce chapitre, nous utiliserons le playbook suivant pour tester les différents filtres présentés : -``` +```bash - name: Manipulating the data hosts: localhost gather_facts: false @@ -78,7 +77,7 @@ Tout au long de ce chapitre, nous utiliserons le playbook suivant pour tester le Le playbook sera exécuté comme suit : -``` +```bash ansible-playbook play-filter.yml ``` @@ -90,7 +89,7 @@ Pour connaitre le type de données (le type d'après le langage Python), vous de Exemple : -``` +```bash - name: Display the type of a variable debug: var: true_boolean|type_debug @@ -98,7 +97,7 @@ Exemple : ce qui nous donne : -``` +```bash TASK [Display the type of a variable] ****************************************************************** ok: [localhost] => { "true_boolean|type_debug": "bool" @@ -107,13 +106,13 @@ ok: [localhost] => { Il est possible de transformer un nombre entier en chaine de caractère : -``` +```bash - name: Transforming a variable type debug: var: zero|string ``` -``` +```bash TASK [Transforming a variable type] *************************************************************** ok: [localhost] => { "zero|string": "0" @@ -122,7 +121,7 @@ ok: [localhost] => { Transformer une chaine de caractères en nombre entier : -``` +```bash - name: Transforming a variable type debug: var: zero_string|int @@ -130,7 +129,7 @@ Transformer une chaine de caractères en nombre entier : ou une variable en booleen : -``` +```bash - name: Display an integer as a boolean debug: var: non_zero | bool @@ -151,7 +150,7 @@ ou une variable en booleen : Une chaine de caractères peut être changée en majuscules ou minuscules : -``` +```bash - name: Lowercase a string of characters debug: var: whatever | lower @@ -163,7 +162,7 @@ Une chaine de caractères peut être changée en majuscules ou minuscules : ce qui nous donne : -``` +```bash TASK [Lowercase a string of characters] ***************************************************** ok: [localhost] => { "whatever | lower": "it's false!" @@ -179,7 +178,7 @@ Le filtre `replace` vous permet de remplacer des caractères par d'autres. Ici, nous supprimons des espaces ou même remplacons un mot : -``` +```bash - name: Replace a character in a string debug: var: whatever | replace(" ", "") @@ -191,7 +190,7 @@ Ici, nous supprimons des espaces ou même remplacons un mot : ce qui nous donne : -``` +```bash TASK [Replace a character in a string] ***************************************************** ok: [localhost] => { "whatever | replace(\" \", \"\")": "It'sfalse!" @@ -205,14 +204,13 @@ ok: [localhost] => { Le filtre `split` une chaîne en une liste basée sur un caractère : -``` +```bash - name: Cutting a string of characters debug: var: whatever | split(" ", "") ``` - -``` +```bash TASK [Cutting a string of characters] ***************************************************** ok: [localhost] => { "whatever | split(\" \")": [ @@ -226,7 +224,7 @@ ok: [localhost] => { Il est fréquent de devoir joindre les différents éléments dans une seule chaîne. Nous pouvons alors spécifier un caractère ou une chaîne à insérer entre chaque élément. -``` +```bash - name: Joining elements of a list debug: var: my_simple_list|join(",") @@ -238,7 +236,7 @@ Il est fréquent de devoir joindre les différents éléments dans une seule cha ce qui nous donne : -``` +```bash TASK [Joining elements of a list] ***************************************************************** ok: [localhost] => { "my_simple_list|join(\",\")": "value_list_1,value_list_2,value_list_3" @@ -257,7 +255,7 @@ Les filtres `dict2items` et `itemstodict`, un peu plus complexe à implémenter, Notez qu'il est possible de spécifier le nom de la clé et de la valeur à utiliser dans la transformation. -``` +```bash - name: Display a dictionary debug: var: my_dictionary @@ -275,7 +273,7 @@ Notez qu'il est possible de spécifier le nom de la clé et de la valeur à util var: my_list | items2dict(key_name='element', value_name='value') ``` -``` +```bash TASK [Display a dictionary] ************************************************************************* ok: [localhost] => { "my_dictionary": { @@ -325,13 +323,13 @@ ok: [localhost] => { Il est possible de fusioner ou de filtrer des données à partir d'une ou plusieurs listes : -``` +```bash - name: Merger of two lists debug: var: my_simple_list | union(my_simple_list_2) ``` -``` +```bash ok: [localhost] => { "my_simple_list | union(my_simple_list_2)": [ "value_list_1", @@ -345,13 +343,13 @@ ok: [localhost] => { Pour garder uniquement l'intersection des deux listes (c'est-à-dire les éléments appartenant à la fois aux deux listes) : -``` +```bash - name: Merger of two lists debug: var: my_simple_list | intersect(my_simple_list_2) ``` -``` +```bash TASK [Merger of two lists] ******************************************************************************* ok: [localhost] => { "my_simple_list | intersect(my_simple_list_2)": [ @@ -362,13 +360,13 @@ ok: [localhost] => { Ou bien au contraire garder uniquement la différence (c'est-à-dire les éléments d'une liste n'appartenant pas à la deuxième) : -``` +```bash - name: Merger of two lists debug: var: my_simple_list | difference(my_simple_list_2) ``` -``` +```bash TASK [Merger of two lists] ******************************************************************************* ok: [localhost] => { "my_simple_list | difference(my_simple_list_2)": [ @@ -380,7 +378,7 @@ ok: [localhost] => { Si votre liste contient des valeurs multiples, vous pouvez aussi utiliser le filtre `unique` : -``` +```bash - name: Unique value in a list debug: var: my_simple_list | unique @@ -390,7 +388,7 @@ Si votre liste contient des valeurs multiples, vous pouvez aussi utiliser le fil Vous pouvez avoir à importer des données json (à partir d'une API par exemple) ou bien exporter des données au format yaml ou json. -``` +```bash - name: Display a variable in yaml debug: var: my_list | to_nice_yaml(indent=4) @@ -400,7 +398,7 @@ Vous pouvez avoir à importer des données json (à partir d'une API par exemple var: my_list | to_nice_json(indent=4) ``` -``` +```bash TASK [Display a variable in yaml] ******************************************************************** ok: [localhost] => { "my_list | to_nice_yaml(indent=4)": "- element: element1\n value: value1\n- element: element2\n value: value2\n" @@ -418,13 +416,13 @@ Vous serez rapidement confronté à des erreurs dans l'exécution de vos playboo La valeur d'une variable peut être remplacée par une autre si elle n'existe pas avec le filtre `default`: -``` +```bash - name: Default value debug: var: variablethatdoesnotexists | default(whatever) ``` -``` +```bash TASK [Default value] ******************************************************************************** ok: [localhost] => { "variablethatdoesnotexists | default(whatever)": "It's false!" @@ -433,13 +431,13 @@ ok: [localhost] => { Notez la présence de l'apostrophe `'` qui doit être protégée, par exemple, si vous utilisez le module `shell`: -``` +```bash - name: Default value debug: var: variablethatdoesnotexists | default(whatever| quote) ``` -``` +```bash TASK [Default value] ******************************************************************************** ok: [localhost] => { "variablethatdoesnotexists | default(whatever|quote)": "'It'\"'\"'s false!'" @@ -448,7 +446,7 @@ ok: [localhost] => { Enfin une variable optionnelle dans un module peut être ignorée si elle n'existe pas avec le mot clé `omit` dans le filtre `default`, ce qui vous permettra d'éviter une erreur à l'exécution. -``` +```bash - name: Add a new user ansible.builtin.user: name: "{{ user_name }}" @@ -461,13 +459,13 @@ Parfois, vous devez utiliser une condition pour assigner une valeur à une varia Ceci peut être évité en utilisant le filtre `ternary` : -``` +```bash - name: Default value debug: var: (user_name == 'antoine') | ternary('admin', 'normal_user') ``` -``` +```bash TASK [Default value] ******************************************************************************** ok: [localhost] => { "(user_name == 'antoine') | ternary('admin', 'normal_user')": "admin" @@ -476,8 +474,8 @@ ok: [localhost] => { ## D'autres filtres - * `{{ 10000 | random }}` : comme son nom l'indique, produit une valeur aléatoire. - * `{{ my_simple_list | first }}` : extrait le premier élément de la liste. - * `{{ my_simple_list | length }}` : donne la longueur (d'une liste ou d'une chaîne). - * `{{ ip_list | ansible.netcommon.ipv4 }}` : n'affiche que les adresses IPv4. Without dwelling on this, if you need, there are many filters dedicated to the network. - * `{{ user_password | password_hash('sha512') }}` : génère un mot de passe haché en sha512. +* `{{ 10000 | random }}` : comme son nom l'indique, produit une valeur aléatoire. +* `{{ my_simple_list | first }}` : extrait le premier élément de la liste. +* `{{ my_simple_list | length }}` : donne la longueur (d'une liste ou d'une chaîne). +* `{{ ip_list | ansible.netcommon.ipv4 }}` : n'affiche que les adresses IPv4. Without dwelling on this, if you need, there are many filters dedicated to the network. +* `{{ user_password | password_hash('sha512') }}` : génère un mot de passe haché en sha512. From 5e495df3a5a2db250697cb788d69f53ccaaaa6aa Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Fri, 26 Apr 2024 03:31:13 -0700 Subject: [PATCH 06/19] New translations 01_rsync_overview.md (French) --- docs/books/learning_rsync/01_rsync_overview.fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/books/learning_rsync/01_rsync_overview.fr.md b/docs/books/learning_rsync/01_rsync_overview.fr.md index 6dcd1ecc06..41800fc2e8 100644 --- a/docs/books/learning_rsync/01_rsync_overview.fr.md +++ b/docs/books/learning_rsync/01_rsync_overview.fr.md @@ -39,7 +39,7 @@ Par conséquent, il doit y avoir une sauvegarde des données dans l'environnemen En termes de support de plate-forme, la plupart des systèmes UNIX ou apparentés sont supportés, qu'il s'agisse de GNU/Linux ou de BSD par exemple. En outre, il y a des logiciels similaires à `rsync` sous la plate-forme Windows, comme cwRsync par exemple. -L'original `rsync` a été maintenu par le programmeur australien Andrew Tridgell (affiché dans la figure 1 ci-dessous), et maintenant il a été maintenu par Wayne Davison (affiché sur la figure 2 ci-dessous) pour maintenance, vous pouvez aller à [ l'adresse du projet github ](https://github.com/WayneD/rsync) pour obtenir les informations que vous voulez. +L'original `rsync` a été maintenu par le programmeur australien Andrew Tridgell (affiché dans la figure 1 ci-dessous) et récemment il a été maintenu par Wayne Davison (affiché sur la figure 2 ci-dessous). Pour la maintenance, vous pouvez aller à [ l'adresse du projet github ](https://github.com/WayneD/rsync) pour obtenir les informations dont vous avez besoin. ![ Andrew Tridgell ](images/Andrew_Tridgell.jpg) ![ Wayne Davison ](images/Wayne_Davison.jpg) From 9d9efe6e8366d61659016121d2bee4a123beb6bd Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sat, 27 Apr 2024 11:38:30 -0700 Subject: [PATCH 07/19] New translations 05-vi.md (Ukrainian) --- docs/books/admin_guide/05-vi.uk.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/books/admin_guide/05-vi.uk.md b/docs/books/admin_guide/05-vi.uk.md index 6247e620b4..e789616376 100644 --- a/docs/books/admin_guide/05-vi.uk.md +++ b/docs/books/admin_guide/05-vi.uk.md @@ -345,11 +345,11 @@ VI дозволяє редагувати текст, керуючи: * Скасувати останню дію: -++u++ +++"u"++ * Скасувати дії в поточному рядку: -++U +++u++ ### Скасувати скасування From a7cfcef0d8083cefb9022da7bb760abb85c9b4a5 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sat, 27 Apr 2024 11:38:41 -0700 Subject: [PATCH 08/19] New translations 02-advanced.md (Ukrainian) --- docs/books/learning_ansible/02-advanced.uk.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/books/learning_ansible/02-advanced.uk.md b/docs/books/learning_ansible/02-advanced.uk.md index e503ae18f1..ee23160da4 100644 --- a/docs/books/learning_ansible/02-advanced.uk.md +++ b/docs/books/learning_ansible/02-advanced.uk.md @@ -8,7 +8,7 @@ title: Ansible. Середній рівень **** -**Цілі**: В цьому розділі ви дізнаєтеся як: +**Цілі**: у цьому розділі ви дізнаєтеся, як: :heavy_check_mark: працювати зі змінними; :heavy_check_mark: використовувати цикли; @@ -466,7 +466,7 @@ tasks: ## Результати вправ -* Напишіть playbook `play-vars.yml`, який друкує назву дистрибутива цільової програми з її основною версією, використовуючи глобальні змінні. +* Напишіть playbook `play-vars.yml, ', який друкує назву дистрибутива цільової програми з її основною версією, використовуючи глобальні змінні. ```bash - hosts: ansible_clients From e0722404a7f466d790a27e1205b2384155038566 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sat, 27 Apr 2024 11:38:51 -0700 Subject: [PATCH 09/19] New translations 03_rsync_demo02.md (Ukrainian) --- docs/books/learning_rsync/03_rsync_demo02.uk.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/books/learning_rsync/03_rsync_demo02.uk.md b/docs/books/learning_rsync/03_rsync_demo02.uk.md index bef2a7656d..103836d506 100644 --- a/docs/books/learning_rsync/03_rsync_demo02.uk.md +++ b/docs/books/learning_rsync/03_rsync_demo02.uk.md @@ -6,6 +6,7 @@ update: 2021-11-04 --- # Демонстрація на основі протоколу rsync + У vsftpd є віртуальні користувачі (імітовані користувачі, налаштовані адміністратором), тому що використовувати анонімних і локальних користувачів небезпечно. Ми знаємо, що сервер, заснований на протоколі SSH, повинен забезпечувати наявність системи користувачів. Коли існує багато вимог до синхронізації, може знадобитися створити багато користувачів. Це, очевидно, не відповідає стандартам роботи та обслуговування GNU/Linux (чим більше користувачів, тим небезпечніше), у rsync з міркувань безпеки існує метод автентифікації протоколу rsync для входу в систему. **Як це зробити?** From 4efc524f86a29aba209330614c08f25e4879f177 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sat, 27 Apr 2024 12:39:17 -0700 Subject: [PATCH 10/19] New translations 06_rsync_inotify.md (Ukrainian) --- docs/books/learning_rsync/06_rsync_inotify.uk.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/books/learning_rsync/06_rsync_inotify.uk.md b/docs/books/learning_rsync/06_rsync_inotify.uk.md index 97c629dd0a..0ee901b3a6 100644 --- a/docs/books/learning_rsync/06_rsync_inotify.uk.md +++ b/docs/books/learning_rsync/06_rsync_inotify.uk.md @@ -62,8 +62,10 @@ fs.inotify.max_user_watches = 1048576 ## Пов'язані команди Інструмент inotify-tools має дві команди, а саме: -* **inotifywait**: для безперервного моніторингу, виведення результатів в реальному часі. Зазвичай він використовується з інструментом інкрементного резервного копіювання rsync. Оскільки це моніторинг файлової системи, його можна використовувати зі сценарієм. Пізніше ми представимо конкретне написання сценарію. -* **inotifywatch**: для короткострокового моніторингу, виведення результатів після виконання завдання. + +* **inotifywait**: для безперервного моніторингу, результати виведення в реальному часі. Зазвичай він використовується з інструментом інкрементального резервного копіювання rsync. Оскільки це моніторинг файлової системи, його можна використовувати зі сценарієм. Конкретний сценарій ми представимо пізніше. + +* **inotifywatch**: виведення результатів після виконання завдання для короткочасного моніторингу. `inotifywait` переважно має наступні параметри: From 6a8dd88c067d17e6c6a08dd5246de346bde7a96d Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sat, 27 Apr 2024 12:40:45 -0700 Subject: [PATCH 11/19] New translations 01-install.md (Ukrainian) --- docs/books/lxd_server/01-install.uk.md | 36 +++++++++++++------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/books/lxd_server/01-install.uk.md b/docs/books/lxd_server/01-install.uk.md index b722c123d7..4da9a975ce 100644 --- a/docs/books/lxd_server/01-install.uk.md +++ b/docs/books/lxd_server/01-install.uk.md @@ -11,19 +11,19 @@ tags: # Розділ 1: Встановлення та налаштування -У цьому розділі вам потрібно буде бути користувачем root або вміти використовувати _sudo_ для отримання прав root. +У цьому розділі вам потрібно буде бути користувачем root або вміти використовувати *sudo* для отримання прав root. ## Встановлення репозиторіїв EPEL і OpenZFS Для LXD потрібен репозиторій EPEL (Extra Packages for Enterprise Linux), який легко встановити за допомогою: -``` +```bash dnf install epel-release ``` Після встановлення перевірте наявність оновлень: -``` +```bash dnf upgrade ``` @@ -33,7 +33,7 @@ dnf upgrade Встановіть репозиторій OpenZFS за допомогою: -``` +```bash dnf install https://zfsonlinux.org/epel/zfs-release-2-2$(rpm --eval "%{dist}").noarch.rpm ``` @@ -41,19 +41,19 @@ dnf install https://zfsonlinux.org/epel/zfs-release-2-2$(rpm --eval "%{dist}").n Для Rocky Linux LXD потрібно інсталювати з оснастки. З цієї причини нам потрібно встановити `snapd` (і кілька інших корисних програм) з: -``` +```bash dnf install snapd dkms vim kernel-devel ``` А тепер увімкніть і запустіть snapd: -``` +```bash systemctl enable snapd ``` А потім запустіть: -``` +```bash systemctl start snapd ``` @@ -63,13 +63,13 @@ systemctl start snapd Встановлення LXD вимагає використання команди snap. На даний момент ми просто встановлюємо його, ми не виконуємо налаштування: -``` +```bash snap install lxd ``` ## Встановлення OpenZFS -``` +```bash dnf install zfs ``` @@ -83,13 +83,13 @@ dnf install zfs Перший файл, який нам потрібно змінити, це файл limits.conf. Цей файл самодокументований, тому подивіться пояснення у файлі щодо того, що він робить. Перегляньте пояснення в коментарях до файлу, щоб зрозуміти, що робить цей файл. Щоб внести зміни, введіть: -``` +```bash vi /etc/security/limits.conf ``` Весь цей файл позначено/закоментовано, а внизу показано поточні налаштування за замовчуванням. У порожньому місці над маркером кінця файлу (#End of file) нам потрібно додати власні налаштування. Коли ви закінчите, кінець файлу виглядатиме як показано нижче: -``` +```text # Modifications made for LXD * soft nofile 1048576 @@ -100,15 +100,15 @@ root hard nofile 1048576 * hard memlock unlimited ``` -Збережіть зміни та вийдіть. (`SHIFT:wq!` для _vi_) +Збережіть зміни та вийдіть. (++shift+colon+"w"+"q"+"exclam++ для *vi*) ### Модифікація sysctl.conf за допомогою 90-lxd.override.conf -За допомогою _systemd_ ми можемо вносити зміни до загальної конфігурації нашої системи та параметрів ядра *без* зміни основного файлу конфігурації. Замість цього ми розмістимо наші параметри в окремому файлі, який просто замінить потрібні нам налаштування. +За допомогою *systemd* ми можемо вносити зміни до загальної конфігурації нашої системи та параметрів ядра *без* зміни основного файлу конфігурації. Замість цього ми розмістимо наші параметри в окремому файлі, який просто замінить потрібні нам налаштування. Щоб внести ці зміни в ядро, ми створимо файл під назвою _90-lxd-override.conf_ у /etc/sysctl.d. Щоб зробити цей тип: -``` +```bash vi /etc/sysctl.d/90-lxd-override.conf ``` @@ -118,7 +118,7 @@ vi /etc/sysctl.d/90-lxd-override.conf Розмістіть наступний вміст у цьому файлі. Зверніть увагу: якщо вам цікаво, що ми тут робимо, вміст файлу нижче є самодокументованим: -``` +```bash ## The following changes have been made for LXD ## # fs.inotify.max_queued_events specifies an upper limit on the number of events that can be queued to the corresponding inotify instance @@ -176,19 +176,19 @@ fs.aio-max-nr = 524288 На цьому етапі вам слід перезавантажити сервер. -### Перевірка значень _sysctl.conf_ +### Перевірка значень *sysctl.conf* Після завершення перезавантаження знову увійдіть на сервер. Нам потрібно перевірити, чи справді наш файл заміни виконав роботу. Це легко зробити. Немає необхідності перевіряти кожне налаштування, якщо ви цього не хочете, але перевірка кількох підтвердить, що налаштування було змінено. Це робиться за допомогою команди _sysctl_: -``` +```bash sysctl net.core.bpf_jit_limit ``` Який повинен показати вам: -``` +```bash net.core.bpf_jit_limit = 3000000000 ``` From 70c596141ac687479cda3f8df4da32f1600a15fb Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sat, 27 Apr 2024 12:40:49 -0700 Subject: [PATCH 12/19] New translations 06-profiles.md (Ukrainian) --- docs/books/lxd_server/06-profiles.uk.md | 78 ++++++++++++------------- 1 file changed, 38 insertions(+), 40 deletions(-) diff --git a/docs/books/lxd_server/06-profiles.uk.md b/docs/books/lxd_server/06-profiles.uk.md index d67576e4a4..83ccfb550e 100644 --- a/docs/books/lxd_server/06-profiles.uk.md +++ b/docs/books/lxd_server/06-profiles.uk.md @@ -29,7 +29,7 @@ tags: Щоб створити наш профіль macvlan, скористайтеся цією командою: -``` +```bash lxc profile create macvlan ``` @@ -37,13 +37,13 @@ lxc profile create macvlan Ви хочете змінити інтерфейс macvlan, але перш ніж це зробити, вам потрібно знати, що таке батьківський інтерфейс для нашого сервера LXD. Це буде інтерфейс, якому призначено IP-адресу локальної мережі (у цьому випадку). Щоб дізнатися, що це за інтерфейс, використовуйте: -``` +```bash ip addr ``` Шукайте інтерфейс із призначенням IP LAN у мережі 192.168.1.0/24: -``` +```bash 2: enp3s0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 40:16:7e:a9:94:85 brd ff:ff:ff:ff:ff:ff inet 192.168.1.106/24 brd 192.168.1.255 scope global dynamic noprefixroute enp3s0 @@ -56,7 +56,7 @@ ip addr Тепер давайте змінимо профіль: -``` +```bash lxc profile device add macvlan eth0 nic nictype=macvlan parent=enp3s0 ``` @@ -64,14 +64,13 @@ lxc profile device add macvlan eth0 nic nictype=macvlan parent=enp3s0 Щоб побачити, що створила ця команда, скористайтеся командою: -``` +```bash lxc profile show macvlan ``` Що дасть вам результат, подібний до цього: - -``` +```bash config: {} description: "" devices: @@ -87,13 +86,13 @@ used_by: [] Щоб призначити профіль macvlan для rockylinux-test-8, нам потрібно зробити наступне: -``` +```bash lxc profile assign rockylinux-test-8 default,macvlan ``` Зробимо те саме для rockylinux-test-9: -``` +```bash lxc profile assign rockylinux-test-9 default,macvlan ``` @@ -115,18 +114,18 @@ lxc profile assign rockylinux-test-9 default,macvlan Щоб перевірити це, просто виконайте такі дії: -``` +```bash lxc restart rocky-test-8 lxc restart rocky-test-9 ``` Перелічіть свої контейнери ще раз і зауважте, що rockylinux-test-9 більше не має IP-адреси: -``` +```bash lxc list ``` -``` +```bash +-------------------+---------+----------------------+------+-----------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-------------------+---------+----------------------+------+-----------+-----------+ @@ -136,19 +135,19 @@ lxc list +-------------------+---------+----------------------+------+-----------+-----------+ | ubuntu-test | RUNNING | 10.146.84.181 (eth0) | | CONTAINER | 0 | +-------------------+---------+----------------------+------+-----------+-----------+ - ``` + Як бачите, наш контейнер Rocky Linux 8.x отримав IP-адресу від інтерфейсу LAN, тоді як контейнер Rocky Linux 9.x ні. Щоб детальніше продемонструвати проблему, вам потрібно запустити `dhclient` у контейнері Rocky Linux 9.0. Це покаже нам, що профіль macvlan *є* фактично застосованим: -``` +```bash lxc exec rockylinux-test-9 dhclient ``` Інший список контейнерів тепер показує наступне: -``` +```bash +-------------------+---------+----------------------+------+-----------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-------------------+---------+----------------------+------+-----------+-----------+ @@ -162,51 +161,51 @@ lxc exec rockylinux-test-9 dhclient Це мало статися з простою зупинкою та запуском контейнера, але цього не відбувається. Припускаючи, що ви хочете щоразу використовувати призначену DHCP IP-адресу, ви можете виправити це за допомогою простого запису crontab. Для цього нам потрібно отримати доступ оболонки до контейнера, ввівши: -``` +```bash lxc exec rockylinux-test-9 bash ``` Далі визначимо повний шлях до `dhclient`. Для цього, оскільки цей контейнер створено з мінімального зображення, вам потрібно спочатку встановити `which`: -``` +```bash dnf install which ``` потім запустіть: -``` +```bash which dhclient ``` який має повернути: -``` +```bash /usr/sbin/dhclient ``` Далі змінимо crontab користувача root: -``` +```bash crontab -e ``` І додайте цей рядок: -``` +```bash @reboot /usr/sbin/dhclient ``` -Введена команда crontab використовує _vi_. Щоб зберегти зміни та вийти, використовуйте SHIFT+:+wq. +Введена команда crontab використовує *vi*. Щоб зберегти зміни та вийти, використовуйте ++shift+colon+"w"+"q"++. Вийдіть із контейнера та перезапустіть rockylinux-test-9: -``` +```bash lxc restart rockylinux-test-9 ``` Інший список показує, що контейнеру призначено адресу DHCP: -``` +```bash +-------------------+---------+----------------------+------+-----------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-------------------+---------+----------------------+------+-----------+-----------+ @@ -225,19 +224,19 @@ lxc restart rockylinux-test-9 Для цього вам потрібно знову отримати доступ оболонки до контейнера: -``` +```bash lxc exec rockylinux-test-9 bash ``` Далі ми створимо сценарій bash у `/usr/local/sbin` під назвою «static»: -``` +```bash vi /usr/local/sbin/static ``` Вміст цього сценарію простий: -``` +```bash #!/usr/bin/env bash /usr/sbin/ip link set dev eth0 name net0 @@ -253,34 +252,33 @@ vi /usr/local/sbin/static * ви відкриваєте новий інтерфейс "net0" * вам потрібно додати маршрут за замовчуванням для нашого інтерфейсу - Зробіть наш сценарій виконуваним за допомогою: -``` +```bash chmod +x /usr/local/sbin/static ``` Додайте це до root-файлу crontab для контейнера з часом @reboot: -``` +```bash @reboot /usr/local/sbin/static ``` Нарешті, вийдіть з контейнера та перезапустіть його: -``` +```bash lxc restart rockylinux-test-9 ``` Зачекайте кілька секунд і знову виведіть список контейнерів: -``` +```bash lxc list ``` Ви повинні побачити успіх: -``` +```bash +-------------------+---------+----------------------+------+-----------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-------------------+---------+----------------------+------+-----------+-----------+ @@ -298,19 +296,19 @@ lxc list Як і у випадку з вашим контейнером rockylinux-test-9, вам потрібно призначити профіль нашому контейнеру: -``` +```bash lxc profile assign ubuntu-test default,macvlan ``` Щоб дізнатися, чи призначає DHCP адресу контейнеру, зупиніть і знову запустіть контейнер: -``` +```bash lxc restart ubuntu-test ``` Потім знову перерахуйте контейнери: -``` +```bash +-------------------+---------+----------------------+------+-----------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-------------------+---------+----------------------+------+-----------+-----------+ @@ -326,13 +324,13 @@ lxc restart ubuntu-test Налаштування статичної IP-адреси трохи відрізняється, але зовсім не складно. Вам потрібно змінити файл .yaml, пов’язаний із з’єднанням контейнера (`10-lxc.yaml`). Для цього статичного IP ви будете використовувати 192.168.1.201: -``` +```bash vi /etc/netplan/10-lxc.yaml ``` Змініть те, що є, на таке: -``` +```bash network: version: 2 ethernets: @@ -348,13 +346,13 @@ network: Перезапустіть контейнер: -``` +```bash lxc restart ubuntu-test ``` Коли ви знову перерахуєте свої контейнери, ви побачите нашу нову статичну IP-адресу: -``` +```bash +-------------------+---------+----------------------+------+-----------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-------------------+---------+----------------------+------+-----------+-----------+ From a85e9d38ae37ea2a705687f2340af674f67156e0 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sat, 27 Apr 2024 12:40:53 -0700 Subject: [PATCH 13/19] New translations 07-configurations.md (Ukrainian) --- docs/books/lxd_server/07-configurations.uk.md | 24 +++++++++---------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/docs/books/lxd_server/07-configurations.uk.md b/docs/books/lxd_server/07-configurations.uk.md index c8bb0373dc..e84b186f08 100644 --- a/docs/books/lxd_server/07-configurations.uk.md +++ b/docs/books/lxd_server/07-configurations.uk.md @@ -15,13 +15,13 @@ tags: Існує велика кількість варіантів налаштування контейнера після його встановлення. Перш ніж їх побачити, давайте розглянемо команду `info` для контейнера. У цьому прикладі ви будете використовувати контейнер ubuntu-test: -``` +```bash lxc info ubuntu-test ``` Це показує щось на зразок наступного: -``` +```bash Name: ubuntu-test Location: none Remote: unix:// @@ -60,7 +60,7 @@ Resources: Там є багато корисної інформації, від застосованих профілів до використовуваної пам’яті, місця на диску тощо. -### Кілька слів про конфігурацію та деякі параметри +## Трохи про конфігурацію та деякі опції За замовчуванням LXD виділить для контейнера необхідну системну пам’ять, дисковий простір, ядра ЦП тощо. Але що, якщо ми хочемо бути більш конкретними? Це цілком можливо. @@ -70,29 +70,29 @@ Resources: Замість того, щоб переглядати всі параметри конфігурації, скористайтеся автозаповненням вкладки, щоб побачити доступні параметри: -``` +```bash lxc config set ubuntu-test ``` -і TAB. +i ++tab++. Це покаже вам усі параметри для налаштування контейнера. Якщо у вас виникли запитання щодо роботи одного з параметрів конфігурації, перейдіть до [офіційної документації для LXD](https://documentation.ubuntu.com/lxd/en/latest/config-options/) і виконайте пошук за параметром конфігурації або весь рядок у Google, наприклад `lxc config set limits.memory`, і подивіться на результати пошуку. Ми розглянемо кілька найбільш використовуваних параметрів конфігурації. Наприклад, якщо ви хочете встановити максимальний обсяг пам’яті, який може використовувати контейнер: -``` +```bash lxc config set ubuntu-test limits.memory 2GB ``` Це говорить про те, що поки пам’ять доступна для використання, іншими словами, є 2 Гб вільної пам’яті, тоді контейнер фактично може використовувати більше 2 Гб якщо вона доступна. Іншими словами, це м’яке обмеження. -``` +```bash lxc config set ubuntu-test limits.memory.enforce 2GB ``` Це говорить про те, що контейнер ніколи не може використовувати більше 2 Гб пам’яті, незалежно від того, доступна вона зараз чи ні. У цьому випадку це жорстке обмеження. -``` +```bash lxc config set ubuntu-test limits.cpu 2 ``` @@ -104,14 +104,13 @@ lxc config set ubuntu-test limits.cpu 2 Пам’ятаєте, коли ми налаштовували наш пул сховищ у розділі про ZFS? Ми назвали пул «сховище», але ми могли назвати його як завгодно. Якщо ми хочемо поглянути на це, ми можемо використати цю команду, яка однаково добре працює для будь-якого іншого типу пулу (як показано для dir): -``` +```bash lxc storage show storage ``` - Це показує наступне: -``` +```bash config: source: /var/snap/lxd/common/lxd/storage-pools/storage description: "" @@ -129,11 +128,10 @@ locations: Це показує, що всі наші контейнери використовують наш пул сховищ dir. Під час використання ZFS ви також можете встановити дискову квоту для контейнера. Ось як це виглядатиме встановлення дискової квоти розміром 2 Гб для контейнера ubuntu-test. -``` +```bash lxc config device override ubuntu-test root size=2GB ``` Як було сказано раніше, ви повинні економно використовувати параметри конфігурації, якщо у вас немає контейнера, який хоче використовувати значно більше, ніж його частка ресурсів. LXD, здебільшого, добре керуватиме середовищем самостійно. Є, звичайно, ще багато варіантів, які можуть зацікавити деяких людей. Ви повинні провести власне дослідження, щоб з’ясувати, чи є щось із цього цінним у вашому середовищі. - From ab50816c65aec1726ba720cbe725e9affce05fe6 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sat, 27 Apr 2024 12:41:03 -0700 Subject: [PATCH 14/19] New translations builtin_plugins.md (Ukrainian) --- .../nvchad/nvchad_ui/builtin_plugins.uk.md | 171 ++++++------------ 1 file changed, 54 insertions(+), 117 deletions(-) diff --git a/docs/books/nvchad/nvchad_ui/builtin_plugins.uk.md b/docs/books/nvchad/nvchad_ui/builtin_plugins.uk.md index e1b97ec72e..23bf4226d3 100644 --- a/docs/books/nvchad/nvchad_ui/builtin_plugins.uk.md +++ b/docs/books/nvchad/nvchad_ui/builtin_plugins.uk.md @@ -2,162 +2,99 @@ title: Вбудовані плагіни author: Franco Colussi contributors: Steven Spencer, Ganna Zhyrnova -tested_with: 8.6, 9.0 +tested_with: 8.8, 9.3 tags: - nvchad - coding - плагіни --- -# Плагіни базової конфігурації +# :material-folder-multiple-outline: Плагіни базової конфігурації -!!! danger "Неправильні інструкції" - - Інструкції на цій сторінці більше не є правильними з випуском версії 2.5; його використання не рекомендується для нових установок. Для отримання додаткової інформації перегляньте [головну сторінку посібника](../index.md). - -!!! примітка "Угода про іменування плагінів" +!!! note "Угода про іменування плагінів" У цій главі формат `user_github/plugin_name` використовуватиметься для ідентифікації плагіна. Це зроблено для того, щоб уникнути можливих помилок із плагінами з подібними назвами та запровадити формат, який використовується для введення плагінів як NvChad, так і `спеціальною` конфігурацією. -Версія 2.0 містить багато нових функцій. Нова версія використовує `lazy.nvim` як менеджер плагінів замість `packer.nvim`; це передбачає внесення деяких змін для користувачів попередньої версії з власною конфігурацією (папка *custom*). - -`lazy.nvim` забезпечує зручне керування плагінами за допомогою єдиного інтерфейсу та інтегрує механізм для синхронізації плагінів між установками (*lazy-lock.json*). - -NvChad зберігає конфігурацію плагінів за умовчанням у файлі *lua/plugins/init.lua*. А додаткові конфігурації різних плагінів містяться в папці */nvim/lua/plugins/configs*. - -Ми можемо побачити уривок файлу *init.lua* нижче: - -```lua -require "core" --- All plugins have lazy=true by default,to load a plugin on startup just lazy=false --- List of all default plugins & their definitions -local default_plugins = { - - "nvim-lua/plenary.nvim", - - { - "NvChad/base46", - branch = "v2.0", - build = function() - require("base46").load_all_highlights() - end, - }, - - { - "NvChad/ui", - branch = "v2.0", - lazy = false, - }, - - { - "NvChad/nvterm", - init = function() - require("core.utils").load_mappings "nvterm" - end, - config = function(_, opts) - require "base46.term" - require("nvterm").setup(opts) - end, - }, -... -... -local lazypath = vim.fn.stdpath "data" .. "/lazy/lazy.nvim" - --- bootstrap lazy.nvim! -if not vim.loop.fs_stat(lazypath) then - require("core.bootstrap").gen_chadrc_template() - require("core.bootstrap").lazy(lazypath) -end - -dofile(vim.g.base46_cache .. "defaults") -vim.opt.rtp:prepend(lazypath) -require "plugins" +Основні плагіни NvChad знаходяться в папці `~/.local/share/nvim/lazy/NvChad/lua/nvchad/plugins/`: + +```text title=".local/share/nvchad/lazy/NvChad/lua/nvchad/plugins/" +├── init.lua +└── ui.lua ``` -Розробники NvChad провели величезну роботу, яку слід відзначити. Вони створили інтегроване середовище серед усіх плагінів, що робить інтерфейс користувача чистим і професійним. Крім того, плагіни, які працюють *під капотом*, дозволяють розширене редагування та інші функції. +і відповідні конфігурації в папці `~/.local/share/nvim/lazy/NvChad/lua/nvchad/configs/`: + +```text title=".local/share/nvchad/lazy/NvChad/lua/nvchad/configs/" +├── cmp.lua +├── gitsigns.lua +├── lazy_nvim.lua +├── lspconfig.lua +├── luasnip.lua +├── mason.lua +├── nvimtree.lua +├── telescope.lua +└── treesitter.lua +``` -Усе це означає, що звичайні користувачі можуть миттєво отримати базову IDE, з якою можна почати роботу, і розширювану конфігурацію, яку можна адаптувати до їхніх потреб. +У папці `plugins` знаходяться файли *init.lua* та *ui.lua*, перший стосується конфігурації плагінів, які пропонують додаткові функції для редактор (*telescope*, *gitsigns*, *tree-sitter* тощо), тоді як останній налаштовує зовнішній вигляд редактора (кольори, піктограми, файловий менеджер тощо). -## Основні плагіни +## :material-download-circle-outline: Основні плагіни Нижче наведено короткий аналіз основних плагінів: -- [nvim-lua/plenary.nvim](https://github.com/nvim-lua/plenary.nvim) – надає бібліотеку поширених функцій lua, які використовуються іншими плагінами, наприклад *telescope* і *gitsigns*. - -- [NvChad/base46](https://github.com/NvChad/base46) – надає теми для інтерфейсу. +=== "init.lua plugins" -- [NvChad/ui](https://github.com/NvChad/ui) – надає фактичний інтерфейс і основні утиліти NvChad. Завдяки цьому плагіну ми можемо мати *рядок стану*, який надає нам інформацію під час редагування, і *рядок вкладок*, який дозволяє щоб керувати відкритими буферами. Цей плагін також містить утиліти **NvChadUpdate** для його оновлення, **NvCheatsheet** для огляду комбінацій клавіш і **Nvdash**, з якого можна виконувати операції з файлами. + - [nvim-lua/plenary.nvim](https://github.com/nvim-lua/plenary.nvim) – надає бібліотеку поширених функцій lua, які використовуються іншими плагінами, наприклад *telescope* і *gitsigns*. -- [NvChad/nvterm](https://github.com/NvChad/nvterm) – надає термінал для нашої IDE, де ми можемо видавати команди. Термінал можна відкрити в буфері різними способами: + - [stevearc/conform.nvim](https://github.com/stevearc/conform.nvim) Плагін форматування для Neovim, швидкий і розширюваний завдяки файлу `configs/conform.lua`, наданому конфігурацією користувача -- `` відкриває термінал, розділяючи буфер горизонтально -- `` відкриває термінал, розділяючи буфер по вертикалі -- `` відкриває термінал у плаваючій вкладці + - [nvim-treesitter/nvim-treesitter](https://github.com/nvim-treesitter/nvim-treesitter) – дозволяє використовувати інтерфейс Treesitter у Neovim і надає деякі основні функціональність, наприклад підсвічування. -- [NvChad/nvim-colorizer.lua](https://github.com/NvChad/nvim-colorizer.lua) – ще один плагін, написаний розробниками NvChad. Це особливо високоефективний хайлайтер. + - [lewis6991/gitsigns.nvim](https://github.com/lewis6991/gitsigns.nvim) – прикрашає *git* зі звітами для доданих, видалених і змінених рядків-звітів, які також інтегровані в *рядок стану*. -- [kyazdani42/nvim-web-devicons](https://github.com/kyazdani42/nvim-web-devicons) – додає піктограми (потрібен один із Nerd Fonts) до типів файлів і папок до нашої IDE. Це дозволяє нам візуально ідентифікувати типи файлів у нашому Провіднику файлів, щоб пришвидшити операції. + - [williamboman/mason.nvim](https://github.com/williamboman/mason.nvim) – дозволяє спрощувати керування встановленням LSP (Language Server) через зручний графічний інтерфейс. -- [lukas-reineke/indent-blankline.nvim](https://github.com/lukas-reineke/indent-blankline.nvim) – надає вказівки для кращого визначення відступів у документі, дозволяючи суб - підпрограми та вкладені команди, які легко розпізнаються. + - [neovim/nvim-lspconfig](https://github.com/neovim/nvim-lspconfig) – надає відповідні конфігурації майже для кожного доступного мовного сервера. Це колекція спільноти з уже встановленими найбільш релевантними параметрами. Плагін піклується про отримання наших конфігурацій і розміщення їх у середовищі редактора. -- [nvim-treesitter/nvim-treesitter](https://github.com/nvim-treesitter/nvim-treesitter) – дозволяє використовувати інтерфейс Treesitter у Neovim і надає деякі основні функціональність, наприклад підсвічування. + - [hrsh7th/nvim-cmp](https://github.com/hrsh7th/nvim-cmp) з відповідними джерелами, наданими плагінами: -- [lewis6991/gitsigns.nvim](https://github.com/lewis6991/gitsigns.nvim) – прикрашає *git* зі звітами для доданих, видалених і змінених рядків-звітів, які також інтегровані в *рядок стану*. + - [L3MON4D3/LuaSnip](https://github.com/L3MON4D3/LuaSnip) + - [saadparwaiz1/cmp_luasnip](https://github.com/saadparwaiz1/cmp_luasnip) + - [hrsh7th/cmp-nvim-lua](https://github.com/hrsh7th/cmp-nvim-lua) + - [hrsh7th/cmp-nvim-lsp](https://github.com/hrsh7th/cmp-nvim-lsp) + - [hrsh7th/cmp-buffer](https://github.com/hrsh7th/cmp-buffer) + - [hrsh7th/cmp-path](https://github.com/hrsh7th/cmp-path) -## Функціональність LSP + - [windwp/nvim-autopairs](https://github.com/windwp/nvim-autopairs) – завдяки цьому плагіну ми маємо функцію автоматичного закриття дужок та інших символів. Наприклад, вставивши початкову дужку `(` завершення автоматично вставить закриваючу дужку `)`, розмістивши курсор посередині. -Тепер давайте перейдемо до плагінів, які забезпечують функціональність для інтеграції LSP (Language Server Protocols) у наші проекти. Це, безумовно, одна з найкращих функцій NvChad. Завдяки LSP ми можемо контролювати те, що пишемо, у режимі реального часу. + - [numToStr/Comment.nvim](https://github.com/numToStr/Comment.nvim) – надає розширені функції для коментування коду. -- [williamboman/mason.nvim](https://github.com/williamboman/mason.nvim) – дозволяє спрощувати керування встановленням LSP (Language Server) через зручний графічний інтерфейс. Надаються такі команди: + - [nvim-telescope/telescope.nvim](https://github.com/nvim-telescope/telescope.nvim) – надає розширені можливості пошуку файлів, має широкі можливості налаштування та також може бути (для прикладу), який використовується для вибору тем NvChad (команда `:Telescope themes`). -- `:Mason` -- `:MasonInstall` -- `:MasonUninstall` -- `:MasonUnistallAll` -- `:MasonLog` + ![Telescope find_files](../images/telescope_find_files.png) -- [neovim/nvim-lspconfig](https://github.com/neovim/nvim-lspconfig) – надає відповідні конфігурації майже для кожного доступного мовного сервера. Це колекція спільноти з уже встановленими найбільш релевантними параметрами. Плагін піклується про отримання наших конфігурацій і розміщення їх у середовищі редактора. +=== "ui.lua plugins" -Він надає такі команди: + - [NvChad/base46](https://github.com/NvChad/base46) – надає теми для інтерфейсу. -- `:LspInfo` -- `:LspStart` -- `:LspStop` -- `:LspRestart` + - [NvChad/ui](https://github.com/NvChad/ui) – надає фактичний інтерфейс і основні утиліти NvChad. Завдяки цьому плагіну ми можемо мати *рядок стану*, який надає нам інформацію під час редагування, і *рядок вкладок*, який дозволяє щоб керувати відкритими буферами. Цей плагін також містить утиліти **NvChadUpdate** для його оновлення, **NvCheatsheet** для огляду комбінацій клавіш і **Nvdash**, з якого можна виконувати операції з файлами. -## Код Lua + - [NvChad/nvim-colorizer.lua](https://github.com/NvChad/nvim-colorizer.lua) – ще один плагін, написаний розробниками NvChad. Це особливо високоефективний хайлайтер. -Після LSP з’являються всі плагіни, які забезпечують функціональність у написанні та виконанні коду Lua, наприклад фрагменти, команди lsp, буфери тощо. Ми не будемо вдаватися в подробиці, але їх можна переглянути у відповідних проектах на GitHub. + - [kyazdani42/nvim-web-devicons](https://github.com/kyazdani42/nvim-web-devicons) – додає піктограми (потрібен один із Nerd Fonts) до типів файлів і папок до нашої IDE. Це дозволяє нам візуально ідентифікувати типи файлів у нашому Провіднику файлів, щоб пришвидшити операції. -Плагіни: + - [lukas-reineke/indent-blankline.nvim](https://github.com/lukas-reineke/indent-blankline.nvim) – надає вказівки для кращого визначення відступів у документі, дозволяючи суб - підпрограми та вкладені команди, які легко розпізнаються. -- [hrsh7th/nvim-cmp](https://github.com/hrsh7th/nvim-cmp) -- [L3MON4D3/LuaSnip](https://github.com/L3MON4D3/LuaSnip) -- [rafamadriz/friendly-snippets](https://github.com/rafamadriz/friendly-snippets) -- [saadparwaiz1/cmp_luasnip](https://github.com/saadparwaiz1/cmp_luasnip) -- [hrsh7th/cmp-nvim-lua](https://github.com/hrsh7th/cmp-nvim-lua) -- [hrsh7th/cmp-nvim-lsp](https://github.com/hrsh7th/cmp-nvim-lsp) -- [hrsh7th/cmp-buffer](https://github.com/hrsh7th/cmp-buffer) -- [hrsh7th/cmp-path](https://github.com/hrsh7th/cmp-path) + - [kyazdani42/nvim-tree.lua](https://github.com/kyazdani42/nvim-tree.lua) – Провідник файлів для Neovim, який дозволяє виконувати найпоширеніші операції з файлами (копіювати, вставити тощо), має інтеграцію з Git, ідентифікує файли з різними значками та іншими функціями. Найважливіше те, що він оновлюється автоматично (це дуже корисно, коли ви працюєте зі сховищами Git). -## Змішані плагіни + ![Дерево Nvim](../images/nvim_tree.png) -- [windwp/nvim-autopairs](https://github.com/windwp/nvim-autopairs) – завдяки цьому плагіну ми маємо функцію автоматичного закриття дужок та інших символів. Наприклад, вставивши початкову дужку `(` завершення автоматично вставить закриваючу дужку `)`, розмістивши курсор посередині. + - [folke/which-key.nvim](https://github.com/folke/which-key.nvim) – відображає всі можливі автозаповнення, доступні для введеної часткової команди. -- [numToStr/Comment.nvim](https://github.com/numToStr/Comment.nvim) – надає розширені функції для коментування коду. + ![Which Key](../images/which_key.png) -## Керування файлами +## Висновки та заключні думки -- [kyazdani42/nvim-tree.lua](https://github.com/kyazdani42/nvim-tree.lua) – Провідник файлів для Neovim, який дозволяє виконувати найпоширеніші операції з файлами (копіювати, вставити тощо), має інтеграцію з Git, ідентифікує файли з різними значками та іншими функціями. Найважливіше те, що він оновлюється автоматично (це дуже корисно, коли ви працюєте зі сховищами Git). - - ![Дерево Nvim](../images/nvim_tree.png) - -- [nvim-telescope/telescope.nvim](https://github.com/nvim-telescope/telescope.nvim) – надає розширені можливості пошуку файлів, має широкі можливості налаштування та також може бути (для прикладу), який використовується для вибору тем NvChad (команда `:Telescope themes`). - - ![Telescope find_files](../images/telescope_find_files.png) - -- [folke/which-key.nvim](https://github.com/folke/which-key.nvim) – відображає всі можливі автозаповнення, доступні для введеної часткової команди. - - ![Which Key](../images/which_key.png) +Розробники NvChad провели величезну роботу, яку слід відзначити. Вони створили інтегроване середовище серед усіх плагінів, що робить інтерфейс користувача чистим і професійним. Крім того, плагіни, які працюють *під капотом*, дозволяють розширене редагування та інші функції. -Ознайомившись із плагінами, які складають базову конфігурацію NvChad, ми можемо перейти до того, як ними керувати. +Це означає, що звичайні користувачі можуть миттєво отримати базову IDE, з якою можна почати роботу, і розширювану конфігурацію, яку можна адаптувати до їхніх потреб. From aa3b257aab59b068bf645cd8df58096318b3f9df Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sun, 28 Apr 2024 05:19:44 -0700 Subject: [PATCH 15/19] New translations 06-large-scale-infrastructure.md (German) --- .../06-large-scale-infrastructure.de.md | 32 +++++++++---------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/docs/books/learning_ansible/06-large-scale-infrastructure.de.md b/docs/books/learning_ansible/06-large-scale-infrastructure.de.md index e24ee49241..7a2d0df49d 100644 --- a/docs/books/learning_ansible/06-large-scale-infrastructure.de.md +++ b/docs/books/learning_ansible/06-large-scale-infrastructure.de.md @@ -10,12 +10,12 @@ In diesem Kapitel erfahren Sie, wie Sie Ihr Konfigurationsmanagementsystem skali **Ziele**: In diesem Kapitel lernen Sie Folgendes: -:heavy_check_mark: Ihren Code für eine große Infrastruktur organisieren; +:heavy_check_mark: Ihren Code für eine große Infrastruktur organisieren; :heavy_check_mark: Ihr Konfigurationsmanagement ganz oder teilweise auf eine Gruppe von Knoten anwenden; :checkered_flag: **Ansible**, **Konfig-Management**, **Skalierung** -**Vorkenntnisse**: :star: :star: :star: +**Vorkenntnisse**: :star: :star: :star: **Schwierigkeitsgrad**: :star: :star: :star: :star: **Lesezeit**: 31 Minuten @@ -52,7 +52,7 @@ Wir haben es hier noch nicht besprochen, aber Sie sollten wissen, dass Ansible a Die Ansible-Dokumentation schlägt vor, unseren Code wie folgt zu organisieren: -``` +```bash inventories/ production/ hosts # inventory file for production servers @@ -82,7 +82,7 @@ Die Verwendung von Ansible-Tags ermöglicht es Ihnen, einen Teil der Aufgaben in Lassen Sie uns zum Beispiel die Aufgabe zur Benutzererstellung ändern: -``` +```bash - name: add users user: name: "{{ item }}" @@ -98,7 +98,7 @@ Lassen Sie uns zum Beispiel die Aufgabe zur Benutzererstellung ändern: Sie können jetzt nur Aufgaben mit dem Tag `users` mit der Option `ansible-playbook` `--tags` abspielen: -``` +```bash ansible-playbook -i inventories/production/hosts --tags users site.yml ``` @@ -110,7 +110,7 @@ Konzentrieren wir uns auf einen Vorschlag zur Organisation von Dateien und Verze Unser Ausgangspunkt wird die Datei `site.yml` sein. Diese Datei ähnelt ein wenig dem CMS-Orchesterleiter, da sie nur bei Bedarf die Rollen enthält, die für die Zielknoten erforderlich sind: -``` +```bash --- - name: "Config Management for {{ target }}" hosts: "{{ target }}" @@ -126,7 +126,7 @@ Natürlich müssen diese Rollen im Verzeichnis `roles` auf derselben Ebene wie d Wir verwalten unsere globalen Variablen gerne in einer Datei `vars/global_vars.yml`, obwohl wir sie auch in einer Datei in `inventories/produktion/group_vars/all.yml` speichern könnten -``` +```bash --- - name: "Config Management for {{ target }}" hosts: "{{ target }}" @@ -141,7 +141,7 @@ Wir verwalten unsere globalen Variablen gerne in einer Datei `vars/global_vars.y Außerdem möchten wir die Möglichkeit behalten, eine Funktion zu deaktivieren. Dann schließen wir meine Rollen mit einer Bedingung und einem Standardwert wie diesem ein: -``` +```bash --- - name: "Config Management for {{ target }}" hosts: "{{ target }}" @@ -160,8 +160,7 @@ Außerdem möchten wir die Möglichkeit behalten, eine Funktion zu deaktivieren. Vergessen Sie nicht, Tags zu verwenden: - -``` +```bash - name: "Config Management for {{ target }}" hosts: "{{ target }}" vars_files: @@ -183,7 +182,7 @@ Vergessen Sie nicht, Tags zu verwenden: Sie sollten so etwas erhalten: -``` +```bash $ tree cms cms ├── inventories @@ -218,7 +217,7 @@ cms Lassen Sie uns das Playbook starten und einige Tests ausführen: -``` +```bash $ ansible-playbook -i inventories/production/hosts -e "target=client1" site.yml PLAY [Config Management for client1] **************************************************************************** @@ -242,14 +241,13 @@ Wie Sie sehen, werden standardmäßig nur Aufgaben aus der Rolle `functionality1 Wir aktivieren `functionality2` für unseren Zielknoten im Inventar und starten das Playbook neu: -``` +```bash $ vim inventories/production/host_vars/client1.yml --- enable_functionality2: true ``` - -``` +```bash $ ansible-playbook -i inventories/production/hosts -e "target=client1" site.yml PLAY [Config Management for client1] **************************************************************************** @@ -273,7 +271,7 @@ client1 : ok=3 changed=0 unreachable=0 failed=0 s Lass uns versuchen, nur `functionality2` anzuwenden: -``` +```bash $ ansible-playbook -i inventories/production/hosts -e "target=client1" --tags functionality2 site.yml PLAY [Config Management for client1] **************************************************************************** @@ -292,7 +290,7 @@ client1 : ok=2 changed=0 unreachable=0 failed=0 s Lassen Sie uns die gesamte Inventur ausführen: -``` +```bash $ ansible-playbook -i inventories/production/hosts -e "target=plateform" site.yml PLAY [Config Management for plateform] ************************************************************************** From 3addb976960c6b13daffc4f3a661131a94ef3f05 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sun, 28 Apr 2024 16:17:55 -0700 Subject: [PATCH 16/19] New translations 03_rsync_demo02.md (French) --- docs/books/learning_rsync/03_rsync_demo02.fr.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/books/learning_rsync/03_rsync_demo02.fr.md b/docs/books/learning_rsync/03_rsync_demo02.fr.md index 183faeeebf..8e1cc47fdc 100644 --- a/docs/books/learning_rsync/03_rsync_demo02.fr.md +++ b/docs/books/learning_rsync/03_rsync_demo02.fr.md @@ -6,6 +6,7 @@ update: 2021-11-04 --- # Démonstration basée sur le protocole rsync + Dans vsftpd, il y a des utilisateurs virtuels (utilisateurs personnalisés par l'administrateur) parce qu'il est très déconseillé d'utiliser des utilisateurs anonymes et des utilisateurs locaux. On sait qu'un serveur basé sur le protocole SSH doit garantir l'existence d'un système d'utilisateurs. Quand il y a beaucoup d'exigences de synchronisation, il peut être nécessaire de créer de nombreux utilisateurs. Cela ne répond évidemment pas aux normes de fonctionnement et de maintenance de GNU/Linux (plus il y a d'utilisateurs, plus il y a d'utilisateurs non sécurisés). Dans rsync, pour des raisons de sécurité, il y a une méthode d'authentification du protocole rsync. **Comment faire?** @@ -17,7 +18,7 @@ Il suffit d'écrire les paramètres et valeurs correspondants dans le fichier de [root@Rocky ~]# vim /etc/rsyncd.conf ``` -Certains paramètres et leurs valeurs de ce fichier sont présentés ci-dessous, [ici](04_rsync_configure.md) vous trouverez d'autres descriptions de paramètres : +Certains paramètres de ce fichier et leurs valeurs sont présentés ci-dessous, [ici](04_rsync_configure.md) vous trouverez des descriptions de paramètres supplémentaires : | Élément | Observation | | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | From 3b5db58cf19a9d5b8f06a8f8becaed560619f9a5 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sun, 28 Apr 2024 16:17:59 -0700 Subject: [PATCH 17/19] New translations 04_rsync_configure.md (French) --- docs/books/learning_rsync/04_rsync_configure.fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/books/learning_rsync/04_rsync_configure.fr.md b/docs/books/learning_rsync/04_rsync_configure.fr.md index 2e39c0877d..0d2115d9b8 100644 --- a/docs/books/learning_rsync/04_rsync_configure.fr.md +++ b/docs/books/learning_rsync/04_rsync_configure.fr.md @@ -6,7 +6,7 @@ update: 2021-11-04 # /etc/rsyncd.conf -Dans l'article précédent [rsync demo 02](03_rsync_demo02.md) nous avons étudié quelques paramètres de base. Cet article est destiné à présenter d'autres paramètres supplémentaires. +Dans l'article précédent [rsync démo 02](03_rsync_demo02.md) nous avons introduit quelques paramètres de base. Cet article est destiné à présenter d'autres paramètres supplémentaires. | Paramètres | Description | | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | From 17c27160f0f895104077e7087196c3bef8318e4a Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sun, 28 Apr 2024 16:18:06 -0700 Subject: [PATCH 18/19] New translations htop.md (French) --- docs/gemstones/htop.fr.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/docs/gemstones/htop.fr.md b/docs/gemstones/htop.fr.md index 239d0ee26e..112f5f47d4 100644 --- a/docs/gemstones/htop.fr.md +++ b/docs/gemstones/htop.fr.md @@ -11,6 +11,7 @@ tags: # htop - Gestion des Processus ## Installation de `htop` + Chaque administrateur système favorise certaines des commandes les plus couramment utilisées. Dans cet article, l'auteur recommande `htop` comme alternative à la commande `top`. Pour utiliser la commande `htop`, en général, vous devez d'abord l'installer. ``` bash @@ -23,9 +24,10 @@ dnf -y install htop ``` ## Utilisation de `htop` + Vous n'avez qu'à taper `htop` dans le terminal et l'interface interactive est la suivante : -``` +```bash 0[ ||| 3%] Tasks: 22, 46thr, 174 kthr 1 running 1[ | 1%] Load average: 0.00 0.00 0.05 Mem[ ||||||| 197M/8G] Uptime: 00:31:39 @@ -34,7 +36,7 @@ PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command(mer ... ``` -F1Help F2Setup F3Search F4Filter F5Tree F6SortBy F7Nice F8Nice+ F9Kill F10Quit +++f1++ Help ++f2++ Setup ++f3++ Search ++f4++ Filter ++f5++ Tree ++f6++ SortBy ++f7++ Nice ++f8++ Nice ++f9++ Kill ++f10++ Quit ### Description de la partie supérieure @@ -84,13 +86,15 @@ PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command(mer * Command - La commande correspondant au processus ### Description des raccourcis -Dans l'interface interactive, appuyez sur le bouton F1 pour voir la description de la touche de raccourci correspondante. -* Les touches de direction haut, bas, gauche et droite peuvent faire défiler l'interface interactive, et ++space++ peuvent marquer le processus correspondant, qui est marqué en jaune. -* Les boutons ++N++, ++P++, ++M++ et ++T++ respectivement PID, CPU%, MEM%, TIME+ sont utilisés pour le tri. Bien sûr, vous pouvez également utiliser la souris pour effectuer un tri ascendant ou descendant d'un certain champ. +Dans l'interface interactive, appuyez sur le bouton ++f1++ pour voir la description de la touche de raccourci correspondante. + +* Les touches de direction haut, bas, gauche et droite peuvent faire défiler l'interface interactive et ++space++ peut accentuer le processus correspondant, qui est marqué en jaune. +* Les boutons ++n++, ++p++, ++m++ et ++t++ respectivement PID, CPU%, MEM%, TIME+ sont utilisés pour le tri. Bien sûr, vous pouvez également utiliser la souris pour effectuer un tri ascendant ou descendant d'un certain champ. ### Autres utilisations courantes -Pour gérer le processus, utilisez le bouton ++F9++ pour envoyer différents signaux. La liste des signaux peut être affichée avec la commande `kill -l`. Les plus couramment utilisées sont : + +Pour gérer le processus, utilisez le bouton ++f9++ et lui envoyer différents signaux. La liste des signaux peut être affichée avec la commande `kill -l`. Les plus couramment utilisées sont : | Signal | Observation | | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -99,4 +103,5 @@ Pour gérer le processus, utilisez le bouton ++F9++ pour envoyer différents sig | 15 | Le signal par défaut pour la commande kill. Parfois, si un problème s'est produit dans le processus et que le processus ne peut pas être terminé normalement avec ce signal, on peut essayer le signal 9 | ## Conclusion + `htop` est beaucoup plus facile à utiliser que la commande `top` qui fait partie du système, il est plus intuitif et améliore grandement l'utilisation au quotidien. C'est pourquoi c'est habituellement la première chose que l'auteur installe après l'installation du système d'exploitation. From d1722ff9d34a9fd97e89877c29fe7a463aa7cd4b Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Mon, 29 Apr 2024 02:30:30 -0700 Subject: [PATCH 19/19] New translations builtin_plugins.md (Ukrainian) --- docs/books/nvchad/nvchad_ui/builtin_plugins.uk.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/books/nvchad/nvchad_ui/builtin_plugins.uk.md b/docs/books/nvchad/nvchad_ui/builtin_plugins.uk.md index 23bf4226d3..bb3fafce90 100644 --- a/docs/books/nvchad/nvchad_ui/builtin_plugins.uk.md +++ b/docs/books/nvchad/nvchad_ui/builtin_plugins.uk.md @@ -36,7 +36,7 @@ tags: └── treesitter.lua ``` -У папці `plugins` знаходяться файли *init.lua* та *ui.lua*, перший стосується конфігурації плагінів, які пропонують додаткові функції для редактор (*telescope*, *gitsigns*, *tree-sitter* тощо), тоді як останній налаштовує зовнішній вигляд редактора (кольори, піктограми, файловий менеджер тощо). +У папці `plugins` знаходяться файли *init.lua* та *ui.lua*. Перший стосується конфігурації плагінів, які пропонують додаткові функції для редактора (*telescope*, *gitsigns*, *tree-sitter* тощо), а останній задає зовнішній вигляд редактора (кольори, іконки, файловий менеджер тощо). ## :material-download-circle-outline: Основні плагіни