You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

1358 lines
37 KiB

  1. #+SETUPFILE: /home/vaab/dev/el/org-html-themes/setup/theme-readtheorg.setup
  2. #+PROPERTY: Effort_ALL 0 0:30 1:00 2:00 0.5d 1d 1.5d 2d 3d 4d 5d
  3. #+PROPERTY: Max_effort_ALL 0 0:30 1:00 2:00 0.5d 1d 1.5d 2d 3d 4d 5d
  4. #+PROPERTY: header-args:python :var filename=(buffer-file-name)
  5. #+PROPERTY: header-args:sh :var filename=(buffer-file-name)
  6. #+TODO: TODO WIP BLOCKED POSTPONED | DONE CANCELED
  7. #+LATEX_HEADER: \usepackage[margin=0.5in]{geometry}
  8. #+LaTeX_CLASS: article
  9. #+OPTIONS: H:8 ^:nil prop:("Effort" "Max_effort") tags:not-in-toc
  10. #+COLUMNS: %50ITEM %Effort(Min Effort) %Max_effort(Max Effort)
  11. #+begin_LaTeX
  12. \hypersetup{
  13. linkcolor=blue,
  14. pdfborder={0 0 0 0}
  15. }
  16. #+end_LaTeX
  17. #+TITLE: Architecture 0k.io
  18. #+LATEX: \pagebreak
  19. * Process de déploiement
  20. Description du process de déploiement pour une nouvelle installation
  21. ** Base myc
  22. *** Qu'est ce c'est ?
  23. A partir d'une debian 9 ou debian 10, on peut installer la machine
  24. pour être prête à utiliser un déploiement myc.
  25. Une fois executé, la machine aura toute les deps pour lancer une
  26. commande compose qui fera peut-être appel à des registry de
  27. mycéliandre. Un compose de base est aussi proposé.
  28. *** Déploiement
  29. **** Hôte linux base debian 9, 10, 11 ou 12, Ubuntu 22.04
  30. ***** Accès ssh standardisé
  31. Via la commande =0km=, depuis votre poste, permet de standardiser
  32. l'accès avec vos clés SSH, et positionner le nom de domaine si
  33. nécessaire.
  34. #+BEGIN_SRC sh
  35. 0km vps-setup HOST
  36. #+END_SRC
  37. Note: ceci fonctionnera que si vous avez un fichier de configuration
  38. dans =/etc/0km/config.yml= (si vous allez l'utiliser en root) ou dans
  39. =~/.config/0km/config.yml= autrement. Ce fichier doit au moins contenir
  40. une clé ssh (ou plusieurs) ainsi:
  41. #+begin_src yaml
  42. ssh-access:
  43. public-keys:
  44. - ssh-rsa AAAAB3NzaC1yc2EAAAAD...qGy20KlAOGPf nom_clef
  45. #+end_src
  46. ***** Déploiement de la solution pour compose
  47. Depuis le VPS, en root:
  48. #+BEGIN_SRC sh
  49. export WITHOUT_DOCKER_CLEAN=1 ## only if you want to remove docker clean from cron
  50. wget https://git.myceliandre.fr/Myceliandre/myc-manage/raw/branch/master/bin/myc-install -qO - | bash
  51. #+END_SRC
  52. Si vous souhaitez positionner le nom de domaine:
  53. #+BEGIN_SRC sh
  54. export WITHOUT_DOCKER_CLEAN=1 ## only if you want to remove docker clean from cron
  55. export DOMAIN=myhost.com
  56. wget https://git.myceliandre.fr/Myceliandre/myc-manage/raw/branch/master/bin/myc-install -qO - | bash
  57. #+END_SRC
  58. ***** Déploiement de la solution pour mailcow
  59. ****** Sur un vps sans mailcow de pre-installé
  60. #+BEGIN_SRC sh
  61. export WITHOUT_DOCKER_CLEAN=1 ## only if you want to remove docker clean from cron
  62. wget https://git.myceliandre.fr/Myceliandre/myc-manage/raw/branch/master/bin/myc-install -qO - | bash
  63. #+END_SRC
  64. ****** Sur un vps avec mailcow de pre-installé
  65. #+BEGIN_SRC sh
  66. export WITHOUT_DOCKER_CLEAN=1 ## only if you want to remove docker clean from cron
  67. export NO_DOCKER_RESTART=1 ## Can use that only if mailcow is pre-existing
  68. wget https://git.myceliandre.fr/Myceliandre/myc-manage/raw/branch/master/bin/myc-install -qO - | bash
  69. #+END_SRC
  70. **** Hôte macosx
  71. - install bash, docker
  72. - Uncheck "Securely store docker logins in macOS keychain"
  73. *** Ce que cela fait
  74. **** Mettre la machine en état charm-ready
  75. - installation du strict minimu pour lancer les =charms=
  76. - téléchargement de la dernière version des =0k-charms= (collection
  77. de recettes d'installation et de gestion de docker)
  78. **** Mettre la machine en état compose ready (notre docker qui va bien)
  79. via le lancement du charm =docker-host= qui installe:
  80. - docker, docker-compose, compose avec des versions qui vont bien
  81. - paquets maisons (kal-scripts, 0k-manage, 0k-pgm, lxc-scripts, 0k-docker)
  82. - accès pour le repository deb de kalysto.org
  83. - clé SSH pour repos git.kal.fr
  84. - login sur le docker registry docker.0k.io
  85. **** Commandes spécifique à myc
  86. - login sur le registry myc
  87. - téléchargement du compose de base dans =/opt/apps/myc-deploy=
  88. ** Modification du compose
  89. *** Qu'est-ce que c'est ?
  90. Il y a des update client à faire souvent sur le compose. Cette étape
  91. doit être externalisée au plus possible, sont consigné ici ce qu'il
  92. faut encore faire à la main.
  93. *** Commande
  94. **** Création de clé OVH pour letsencrypt/lexicon
  95. Ceci n'est nécessaire qu'en cas d'utilisation de la méthode DNS
  96. pour valider la possession du domaine auprès de letsencrypt.
  97. #+BEGIN_SRC shell
  98. APPLICATION_KEY=XXXXXXXXXXXXXXXXX
  99. REDIR_WEBSITE=https://0k.io
  100. req=$(cat <<EOF
  101. {
  102. "accessRules": [
  103. {
  104. "method": "GET",
  105. "path": "/*"
  106. },
  107. {
  108. "method": "POST",
  109. "path": "/*"
  110. },
  111. {
  112. "method": "PUT",
  113. "path": "/*"
  114. },
  115. {
  116. "method": "DELETE",
  117. "path": "/*"
  118. }
  119. ],
  120. "redirection":"$REDIR_WEBSITE"
  121. }
  122. EOF
  123. )
  124. res=$(curl -X POST \
  125. -H "X-Ovh-Application: ${APPLICATION_KEY}" \
  126. -H "Content-type: application/json" \
  127. https://eu.api.ovh.com/1.0/auth/credential \
  128. -d "$req")
  129. consumer_key=$(echo "$res" | jq -r .consumerKey)
  130. validation_url=$(echo "$res" | jq -r .validationUrl)
  131. echo "Visit: $validation_url"
  132. echo "ConsumerKey: $consumer_key"
  133. #+END_SRC
  134. Il s'agit alors de remplir le compose.yml
  135. #+BEGIN_SRC yaml
  136. ovh:
  137. ## see: https://api.ovh.com/g934.first_step_with_api
  138. entrypoint: ovh-eu
  139. application:
  140. key: XXXXXXXXXXXXXXXX
  141. secret: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
  142. consumer_key: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
  143. #+END_SRC
  144. Puis de valider que tout est ok:
  145. #+BEGIN_SRC shell
  146. check-compose-ovh-credentials compose.yml
  147. #+END_SRC
  148. ** Lancement/Deploy de service odoo
  149. *** Qu'est ce que c'est ?
  150. A partir d'une base myc, cette commande permet d'envoyer la
  151. construction et l'assemblage de tous les services décrit dans le
  152. =compose.yml= fourni par défaut.
  153. *** commandes
  154. #+BEGIN_SRC sh
  155. cd /opt/apps/myc-deploy
  156. compose --debug up odoo frontend
  157. #+END_SRC
  158. De manière générale:
  159. #+BEGIN_SRC sh
  160. compose [--debug] up [SERVICES...]
  161. #+END_SRC
  162. *** Ce que ça fait
  163. Les charms vont s'occuper de séparer la config des
  164. donnée, de tout stocker dans =/srv/datastore=, il vont
  165. s'occuper de la petite maintenance:
  166. - le charm postgres (qui est une dépendance du service odoo) va créer
  167. un mot de passe et le filer à odoo
  168. - le charm apache (qui implémente le service frontend)
  169. va créer les fichiers de conf apache pour déclarer un virtualhost
  170. et mettre les clés SSL s'il y a lieu.
  171. * Gestion
  172. Description des process de gestion d'une installation existante.
  173. ** Connection aux serveurs
  174. *** installation commande =st=
  175. Le mieux est d'utiliser la commande =st= que l'on peut installer ainsi
  176. sur un poste linux ayant =apt=:
  177. Se mettre en =root=:
  178. #+begin_src sh
  179. cat <<'EOF' > /usr/local/bin/st
  180. #!/bin/bash
  181. echo "Trying mosh to $1"
  182. TERM=xterm-256color mosh "$1" -- bash -c "tmux attach || { tmux; }"
  183. if [ "$?" == "5" ]; then
  184. echo "Fallback to ssh $1"
  185. ssh "$1" -tM "TERM=xterm-256color tmux attach || TERM=xterm-256color tmux"
  186. fi
  187. EOF
  188. chmod +x /usr/local/bin/st
  189. apt install mosh
  190. #+end_src
  191. *** utilisation de la commande =st=
  192. =st= utilise =ssh= ou =mosh= et se met dans un =tmux= sur la destination.
  193. #+begin_src sh
  194. st root@monvps.fr
  195. #+end_src
  196. On note qu'il faut penser à mettre les clé SSH sur la destination.
  197. ** Mise à jour de l'ensemble
  198. Pour mettre à jour un VPS:
  199. #+BEGIN_SRC sh
  200. myc-update
  201. #+END_SRC
  202. Cette commande va ré-appliquer l'installation du charm =docker-host=
  203. qui installe ou met à jour chaque composant.
  204. *** Mise à jour de docker
  205. Par défaut =myc-update= ne met pas à jour le service docker pour éviter
  206. de couper les services. Si cela est souhaité, il est possible de faire:
  207. #+begin_src sh
  208. ALLOW_DOCKER_CHANGE=1 myc-update
  209. #+end_src
  210. Aussi, par défaut, =myc-update= pré-selectionne une version cible commune de
  211. docker pour une distribution donnée.
  212. ** Gestion des dockers
  213. *** Relancement
  214. si on veut relancer parce que le compose a changé :
  215. on fait pareil qu'au lancement : lors du "up", docker-compose se
  216. rend compte que la définition des services a changé et relance les
  217. docker voulu.
  218. *** Arrêt
  219. #+BEGIN_SRC sh
  220. compose --debug down
  221. #+END_SRC
  222. *** Voir les logs
  223. #+BEGIN_SRC sh
  224. cd /opt/apps/myc-deploy
  225. compose --debug logs odoo
  226. #+END_SRC
  227. *** Obtenir les IPs des dockers
  228. #+BEGIN_SRC sh
  229. docker-ip
  230. #+END_SRC
  231. *** Obtenir des statistiques d'utilisation des resources
  232. **** Consommation
  233. La commande ~docker stats~ permet d'afficher en temps réel la consommation des
  234. différentes ressources (mémoire, processeur, réseau...).
  235. À noter, la commande ~vps stats~ fait la même chose, et rempli la base
  236. de donnée pour l'historique des utilisations. Cette commande est
  237. normalement lancée par cron régulièrement.
  238. Les bases de données d'utilisation sont stockée dans ~/var/lib/vps/rrd~
  239. **** Historique de la consommation des ressources
  240. Depuis ~0km~ il est possible de grapher les informations d'un VPS:
  241. #+begin_src sh
  242. 0km vps-stats [--timespan START[..END]] VPS [VPS...]
  243. #+end_src
  244. Exemples:
  245. #+begin_src sh
  246. 0km vps-stats vps-{01,02}.0k.io ## dernier jour de donnée
  247. 0km vps-stats vps-{01,02}.0k.io -t e-1w ## end moins 1 semaine de donnée
  248. 0km vps-stats vps-{01,02}.0k.io -t e-5d ## end moins 5 jours de donnée
  249. 0km vps-stats vps-01.0k.io -t n-3h..n-2h ## now(maintenant) moins 3h à now moins 2h
  250. 0km vps-stats vps-01.0k.io -t 17:40..17:50 ## de 17:40 à 17:50 (heure locale !)
  251. 0km vps-stats vps-01.0k.io -t "20230811..17:50" ## du début de la journée de 2023-08-11 à 17:50 ajd
  252. ## graphe dynamique qui se met à jour sur les 2 dernière heures
  253. 0km vps-stats vps-01.0k.io -t "n-2h" -f
  254. #+end_src
  255. Pour plus de détail sur le format de début et de fin, se rapporter à
  256. la fin de la page man de [[https://linux.die.net/man/1/rrdfetch][rrdfetch]].
  257. *** Limiter la mémoire utilisée par un container
  258. Certains container vont demander beaucoup de memoire par défaut et
  259. doivent être contenu dans des environment limités.
  260. Aussi, on peut limiter la mémoire d'un docker dans le fichier
  261. =compose.yml=:
  262. #+begin_src yaml
  263. mon-service:
  264. # ...
  265. docker-compose:
  266. mem_limit: 2g
  267. memswap_limit: 2g ## Au cas où l'on a du swap
  268. # ...
  269. #+end_src
  270. *** Vérification de santé générale
  271. La commande =vps check-fix= contrôler les containers en cours de
  272. fonctionnement pour vérifier s'ils ne sont pas touché par quelques
  273. problème identifiés et connus. Et elle va réparer ce qu'elle peut.
  274. #+begin_src sh
  275. vps check-fix
  276. #+end_src
  277. Il est possible de lancer ces vérifications sur une liste de service
  278. spécifique ou de sélectionner le test voulu. Voir =vps check-fix
  279. --help= pour plus d'info.
  280. Il peut être opportun d'ajouter dans sur l'hôte, par exemple, une
  281. vérification périodique et automatique:
  282. #+begin_src sh
  283. cat <<EOF > /etc/cron.d/vps-check
  284. SHELL=/bin/bash
  285. PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
  286. */15 * * * * root vps check-fix -s -c container-aliveness 2>&1 | logger -t check-fix
  287. */5 * * * * root vps check-fix -s rocketchat 2>&1 | logger -t check-fix
  288. EOF
  289. #+end_src
  290. ** Par services
  291. *** odoo
  292. **** Backups
  293. ***** Backuping odoo account (filestore and database)
  294. ****** Via =vps= command
  295. A few examples:
  296. #+begin_src sh
  297. ## dump default database of default service to file db.zip
  298. vps odoo dump db.zip
  299. ## dump default database of 'odoo2' service
  300. vps odoo dump /tmp/db.zip -s odoo2
  301. ## dump 'odoodev' database of default 'odoo' service
  302. vps odoo dump /tmp/db.zip -d odoodev
  303. #+end_src
  304. ****** Via charm only actions
  305. Be sure that your odoo instance should be already up.
  306. #+BEGIN_SRC sh
  307. MYODOOSERVICENAME=odoo
  308. DBNAME="$MYODOOSERVICENAME"
  309. OUTPUTFILE=backup-odoo.zip
  310. compose save "$MYODOOSERVICENAME" "$DBNAME" > "$OUTPUTFILE"
  311. #+END_SRC
  312. ***** Restoring odoo account (filestore and database)
  313. *IMPORTANT* you might want to consider the usage of =docker-cutoff= if
  314. you are restoring a production odoo onto a dev or staging odoo that you
  315. don't want to allow to go mess around with sending mails or fetching mails.
  316. #+BEGIN_SRC yaml
  317. docker-cutoff 25 993 465
  318. #+END_SRC
  319. ****** Via =vps= command
  320. #+begin_src sh
  321. ## restore default database of default service from file db.zip
  322. vps odoo restore db.zip
  323. ## restore default database of 'odoo2' service
  324. vps odoo restore /tmp/db.zip -s odoo2
  325. ## restore 'odoodev' database of default 'odoo' service
  326. vps odoo restore /tmp/db.zip -D odoodev
  327. ## restore on database of default 'odoo' service, and neutralize the restored base
  328. vps odoo restore -n /tmp/db.zip
  329. #+end_src
  330. ****** Via standard charm action
  331. Be sure that your odoo instance is already up.
  332. These are the normal loading instructions:
  333. #+BEGIN_SRC sh
  334. MYODOOSERVICENAME=odoo
  335. DBNAME="$MYODOOSERVICENAME"
  336. SOURCEFILE=backup-odoo.zip
  337. compose load "$MYODOOSERVICENAME" "$DBNAME" < "$SOURCEFILE"
  338. #+END_SRC
  339. **** Update de modules
  340. #+BEGIN_SRC sh
  341. compose update odoo MABASE [MODULE [MODULE ...]]
  342. #+END_SRC
  343. **** lancement d'une commande odoo
  344. Si l'ensemble n'est pas up:
  345. #+BEGIN_SRC sh
  346. compose --debug run odoo --help
  347. #+END_SRC
  348. **** Mod dev d'odoo
  349. Il est souhaitable de lancer odoo en mode dev avec un terminal prêt à
  350. accueillir un pdb par exemple, et pouvoir changer facilement la ligne de commande.
  351. On peut tout a fait lancer odoo directement, par exempe:
  352. #+BEGIN_SRC sh
  353. compose run --rm --use-aliases odoo --dev=wdb --config=/opt/odoo/auto/odoo.conf
  354. #+END_SRC
  355. On récupère ainsi tous les volumes et autres options (sauf ce qui est
  356. dans =command:=) défini dans =compose.yml=.
  357. Un problème cependant: si on utilise apache comme frontend, celui-ci
  358. ne pourra pas résoudre le nom =odoo= à cause de problèmes autour de
  359. =docker-compose= et/ou =docker network=. En effet, si on fait un =up=
  360. comme d'habitude, et qu'on souhaite simplement arrêter le service
  361. classique pour ensuite le remplacer par la commande au dessus, cela ne
  362. fonctionnera pas. En effet, l'alias réseau =odoo= n'est plus adjoignable
  363. (même avec les commandes =docker network {dis,}connect=), et même si
  364. le container original de odoo est détruit ou éjecté du réseau, ou que l'on
  365. essaye de connecter soi-même le nouveau container.
  366. Un moyen (bancal) de passer outre cependant:
  367. - =down= pour fermer le réseau
  368. - =create= sur le service apache, puis =restart=.
  369. - enfin, le =run= tel que décrit au dessus
  370. Soit:
  371. #+BEGIN_SRC sh
  372. compose down &&
  373. compose create apache &&
  374. compose restart apache &&
  375. compose run --rm --use-aliases odoo --dev=wdb --config=/opt/odoo/auto/odoo.conf
  376. #+END_SRC
  377. Le container odoo crée par la dernière ligne se retirera proprement des tables DNS
  378. interne, et donc peut tout a fait être relancée autant de fois que l'on souhaitera.
  379. **** Single Sign On en carafe
  380. L'installation du module =website= et =galicia= pour l'authentication
  381. Single Sign On peut aboutir à une situation où le sign on est
  382. automatique et arrive sur un mauvais utilisateur.
  383. Il s'agit de l'utilisateur attaché à l'objet =website= surlequel le sign on
  384. du service tiers a été configuré pour pointer.
  385. En effet, l'objet ~website~ possède un ~user_id~ qui va être utilisé en guise
  386. d'utilisateur par défaut. Si celui-ci ne correspond pas à l'utilisateur odoo ~public_user~,
  387. alors =galicia= considère que cet utilisateurs est déjà loggé et offre son accès.
  388. La solution est de forcer le ~user_id~ des objets ~website~ à l'id de l'utilisateur ~public_user~.
  389. C'est ce que fait la commande:
  390. #+begin_src sh
  391. vps odoo fix-sso
  392. #+end_src
  393. *** letsencrypt
  394. Le service letsencrypt fourni des certificat SSL à la demande et les
  395. renouvelle automatiquement.
  396. **** configuration dans compose
  397. ***** Authentification HTTP
  398. Il n'y a besoin d'aucune option dans le service =letsencrypt=.
  399. Le charm =apache= doit trouver un service utilisant le charm =letsencrypt=, cette
  400. connection se fera automatiquement si un servce de type =letsencrypt= est lancé soit
  401. parce que directement mentionné dans la racine ou dans une relation explicite.
  402. La relation construite automatiquement (ou manuellement) d'un service
  403. =apache= vers un service =letsencrypt= s'appelle =cert-provider=.
  404. Une fois que ce service est relié à apache, on peut s'en servir comme clé dans
  405. la configuration =ssl= des relations =*-->web-proxy-->apache=.
  406. Par défaut, =apache= utilisera du ssl pour tout se virtual-host s'il trouve un
  407. =cert-provider= à disposition.
  408. Aussi la configuration suivante est suffisante pour avoir un site publié en SSL:
  409. #+BEGIN_SRC yaml
  410. www.mydomain.org:
  411. charm: odoo
  412. apache:
  413. letsencrypt:
  414. #+END_SRC
  415. Cela équivaut à :
  416. #+BEGIN_SRC yaml
  417. www.mydomain.org:
  418. charm: odoo
  419. relations:
  420. web-proxy:
  421. myapache:
  422. domain: www.mydomain.org
  423. ssl:
  424. myletsencrypt:
  425. challenge-type: http
  426. myapache:
  427. charm: apache
  428. myletsencrypt:
  429. charm: letsencrypt
  430. #+END_SRC
  431. ***** Authentification DNS
  432. ****** créer un nouveau jeu de clé OVH pour l'authentification DNS
  433. When =letsencrypt= is setup and running::
  434. #+BEGIN_SRC sh
  435. compose --debug add letsencrypt DOMAIN [DOMAIN...]
  436. #+END_SRC
  437. Exemple de setup (dans =compose.yml=):
  438. #+BEGIN_SRC yaml
  439. letsencrypt:
  440. options:
  441. email: admin@0k.io
  442. ovh:
  443. entrypoint: ovh-eu
  444. application:
  445. key: ZZZ
  446. secret: XXX
  447. consumer_key: YYYYY
  448. #+END_SRC
  449. Le résultat est dans =/srv/datastore/data/letsencrypt/etc/letsencrypt/live/DOMAIN1=
  450. Il apparaît entre 30sec et 1 minute après la demande.
  451. ****** Vérifier que le jeu de clé ovh est bon
  452. Cette commande prend le compose yml et va vérifier que les accès sont valides:
  453. #+BEGIN_SRC shell
  454. check-compose-ovh-credentials compose.yml
  455. #+END_SRC
  456. **** Utilisation manuelle
  457. On peut utiliser le service =letsencrypt= manuellement
  458. ***** creation d'un certificat http
  459. #+BEGIN_SRC shell
  460. compose crt letsencrypt create DOMAIN [DOMAIN...]
  461. #+END_SRC
  462. Cette action crée un certificat (et force le renouvellement si existant).
  463. On peut y injecter une configuration via =--add-compose-content= si nécessaire::
  464. #+BEGIN_SRC shell
  465. compose --add-compose-content='
  466. letsencrypt:
  467. ovh:
  468. ## see: https://api.ovh.com/g934.first_step_with_api
  469. entrypoint: ovh-eu
  470. application:
  471. key: XXX
  472. secret: YYY
  473. consumer_key: ZZZ
  474. challenge-type: dns
  475. #renew-before-expiry: 30' crt letsencrypt create DOMAIN [DOMAIN...]
  476. #+END_SRC
  477. ***** Renew de tous les certificats
  478. Cela renew uniquement les certificats dont la date de validité est inférieure à 30j
  479. #+BEGIN_SRC shell
  480. compose crt letsencrypt renew
  481. #+END_SRC
  482. ***** Liste des certificats gérés et infos connexes
  483. #+BEGIN_SRC shell
  484. compose run letsencrypt crt list
  485. #+END_SRC
  486. ***** suppression d'un certificat
  487. #+BEGIN_SRC shell
  488. compose run letsencrypt certbot delete --cert-name DOMAIN
  489. #+END_SRC
  490. *** apache
  491. **** Utiliser letsencrypt
  492. Pour ajouter la fonctionalité de génération automatique de certificat
  493. via le service =letsencrypt=, il faut:
  494. - déclarer un service =letsencrypt= si cela n'est pas déjà fait
  495. - le lier au charm apache via une relation =cert-provider=:
  496. #+BEGIN_SRC yaml
  497. frontend:
  498. charm: apache
  499. relations:
  500. cert-provider: letsencrypt
  501. letsencrypt:
  502. ...
  503. #+END_SRC
  504. Et l'on peut alors utiliser la valeur =letsencrypt= (le nom du service qui implémente
  505. qui est en relation =cert-provider= avec apache) dans le champ =ssl=::
  506. #+BEGIN_SRC yaml
  507. web-proxy:
  508. apache:
  509. ...
  510. ssl: letsencrypt
  511. #+END_SRC
  512. **** Changer les clés SSL
  513. Voici un exemple de ce qu'on peut mettre dans les options de la relation apache
  514. pour déclarer le certificat que l'on souhaite:
  515. #+BEGIN_SRC yaml
  516. ssl:
  517. ca-cert:
  518. -----BEGIN CERTIFICATE-----
  519. MIIF6TCCA9GgAwIBAgIQBeTcO5Q4qzuFl8umoZhQ4zANBgkqhkiG9w0BAQwFADCB
  520. iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0pl
  521. ...
  522. m9T8bJUox04FB6b9HbwZ4ui3uRGKLXASUoWNjDNKD/yZkuBjcNqllEdjB+dYxzFf
  523. BT02Vf6Dsuimrdfp5gJ0iHRc2jTbkNJtUQoj1iM=
  524. -----END CERTIFICATE-----
  525. -----BEGIN CERTIFICATE-----
  526. MIIFdzCCBF+gAwIBAgIQE+oocFv07O0MNmMJgGFDNjANBgkqhkiG9w0BAQwFADBv
  527. MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
  528. ...
  529. Le9Gclc1Bb+7RrtubTeZtv8jkpHGbkD4jylW6l/VXxRTrPBPYer3IsynVgviuDQf
  530. Jtl7GQVoP7o81DgGotPmjw7jtHFtQELFhLRAlSv0ZaBIefYdgWOWnU914Ph85I6p
  531. 0fKtirOMxyHNwu8=
  532. -----END CERTIFICATE-----
  533. cert: |
  534. -----BEGIN CERTIFICATE-----
  535. MIIF/TCCBOWgAwIBAgIRALUydpTpCApfYMuJchDJv5AwDQYJKoZIhvcNAQELBQAw
  536. XzELMAkGA1UEBhMCRlIxDjAMBgNVBAgTBVBhcmlzMQ4wDAYDVQQHEwVQYXJpczEO
  537. ...
  538. lIxY9HJanHrWvjiz7+eToxXpZJtAPXTx5hxzcJrtWROlq7IJCMIhzr/EVA37jTCk
  539. Xs5S6mr0T6Dqx6MQkPATSsEEJlLH5wq3DxXQcrMqnM/WHMRYUCkoTl37sXplflHe
  540. jw==
  541. -----END CERTIFICATE-----
  542. key: |
  543. -----BEGIN PRIVATE KEY-----
  544. MIIJRQIBADANBgkqhkiG9w0BAQEFAASCCS8wggkrAgEAAoICAQDONqqTCS4CiSi/
  545. XeNpp2nUsq1299spGc7mlRs+PDrXNHscB5lUB5/yo2yEetYXrJacQ8n4NV9hkID5
  546. ...
  547. 44eHDYsofcnRbidGR+QT8PQgiiDNCkbpi2u4QnLTs0w4oW+53ZTyHYEYF2rcLbIb
  548. vRt4kR4KG6ULXrmsRA4WQjBDJ9vZw2aK+w==
  549. -----END PRIVATE KEY-----
  550. #+END_SRC
  551. **** Ajouter des rêgles particulière de apache
  552. #+BEGIN_SRC yaml
  553. relations:
  554. web-proxy:
  555. apache:
  556. ...
  557. apache-custom-rules: |
  558. RewriteEngine On
  559. RewriteCond %{HTTPS} off
  560. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=302,L,QSA]
  561. #+END_SRC
  562. **** Vérification des derniers logs de renouvellement automatique
  563. #+BEGIN_SRC shell
  564. tail -f /srv/datastore/data/cron/var/log/cron/letsencrypt-renew_script.log -n 200
  565. #+END_SRC
  566. *** postgres
  567. **** utilisation de pgm
  568. récupérer l'IP du docker postgres via =docker-ip=
  569. #+BEGIN_SRC sh
  570. PGHOST=172.19.0.2 PGUSER=postgres pgm ls
  571. #+END_SRC
  572. **** base corrompue, réparation
  573. Il s'agit de lancer un =pg_resetwal=, il faut veiller à plusieurs élément:
  574. - bien arréter tout process utilisant le répertoire de =data= du
  575. postgres en question, généralement un =compose stop postgres=
  576. suffit.
  577. - utiliser l'image du postgres via son nom (habituellement =myc_postgres=).
  578. - monter le répertoire data =directement=
  579. Le tout peut se faire ainsi dans une installation qui fait tourner un postgres
  580. actuellement:
  581. #+begin_src sh
  582. compose stop postgres &&
  583. docker run --rm --entrypoint pg_resetwal \
  584. -u postgres -v /srv/datastore/data/postgres/var/lib/postgresql/data:/var/lib/postgresql/data \
  585. myc_postgres \
  586. /var/lib/postgresql/data &&
  587. docker start myc_postgres_1
  588. #+end_src
  589. *** mysql
  590. **** sur installation mailcow
  591. Le script =vps= fourni via =myc-manage=, permet la commande =vps
  592. install backup MYBACKUPDEST=, qui s'occupe de mettre en place le dump
  593. de =mysql=, et le système pour envoyer les backup régulièrement via
  594. rsync.
  595. **** docker sans compose
  596. #+begin_src sh
  597. export MYSQL_ROOT_PASSWORD=xxx
  598. export MYSQL_CONTAINER=mailcowdockerized_mysql-mailcow_1
  599. /srv/charm-store/mysql/hooks/install.d/60-backup.sh
  600. #+end_src
  601. *** rsync-backup
  602. **** Installation du backup de compose / mailcow
  603. Les commandes suivantes permettent l'installation du backup sur les
  604. deux type de serveur suivant :
  605. - un serveur =compose= est un serveur ayant des services géré par
  606. =compose= à backupper.
  607. - un serveur =mailcow= est un serveur faisant tourner l'installation =mailcow=.
  608. ***** Via la commande 0km sur un hôte admin
  609. L'instruction suivante doit être executée sur un hôte ayant la
  610. commande =0km= d'installée et les accès SSH vers le VPS et un compte
  611. d'administration du service =rsync-backup-target= sur le serveur
  612. d'archivage.
  613. Dans l'exemple suivant on utilise le compte administration du service
  614. =rsync-backup-target= nommé =myadmin=... pour avoir la liste des
  615. compte admin, se reporter au contenu du fichier =compose.yml= sur le
  616. serveur d'archivage et plus spécifiquement la configuration du service
  617. =rsync-backup-target=. Les noms des comptes admin y sont défini ainsi
  618. que les clés publiques y ayant accès.
  619. #+begin_src sh
  620. 0km vps-install backup myadmin@core-06.0k.io:10023 myvps.fr
  621. #+end_src
  622. Note: on peut spécifier autant de vps que l'on souhaite en fin de
  623. ligne de commande. L'installation des vps se fera en parallèle et
  624. vers le serveur d'archive spécifié en premier argument.
  625. Note: cette commande peut-être executé plusieurs fois sur le même
  626. hôte : si tout est déjà installé, cette commande n'aura pour seul
  627. effet que de relancer une synchronisation vers le backup.
  628. ***** Via la commande vps sur le vps lui-même
  629. A faire depuis le serveur compose ou mailcow:
  630. #+begin_src sh
  631. vps install backup core-06.0k.io:10023
  632. #+end_src
  633. Ici =core-06.0k.io:10023= est le serveur cible d'archivage (à modifier
  634. si nécessaire).
  635. A la fin de l'opération, une commande est proposée pour ajouter
  636. facilement la nouvelle clé à l'hôte s'occupant de l'archivage.
  637. Cette commande doit être executée sur un hôte ayant les accès vers un
  638. compte administration du serveur d'archivage.
  639. Dans le cas d'un VPS sur installation compose, il s'agira également de
  640. relancer sur le VPS lui-même, un =compose up= pour intégrer et lancer
  641. le nouveau container de backup.
  642. Une fois la clé enregistrée du coté du serveur d'archivage, un premier
  643. archivage peut être déclenché via:
  644. #+begin_src sh
  645. vps backup
  646. #+end_src
  647. Ceci permet de lancer le premier backup et de valider que tout fonctionne
  648. **** Installation du backup sur un host debian
  649. Cela fonctionnera sur tout host ayant une base debian.
  650. #+begin_src sh
  651. DOMAIN=mail.xxxx.fr
  652. BACKUP_SERVER=core-06.0k.io:10023
  653. cd /srv/charm-store/rsync-backup/
  654. ./hooks/install.d/60-install.sh
  655. #+end_src
  656. Note, il est possible de spécifier des exclusions pour chaque
  657. répértoire mirroré de telle façon:
  658. #+begin_src sh
  659. cat <<EOF >> /etc/mirror-dir/config.yml
  660. /home:
  661. exclude:
  662. - /*/.cache/
  663. - /*/.gvfs/
  664. - /*/.local/share/Trash/files/
  665. - /*/.Trash/
  666. - /*/.mozilla/firefox/*/Cache/
  667. - /*/.mozilla/firefox/*/storage/default/*/cache/
  668. /media/data:
  669. exclude:
  670. - /binary/games/_steam
  671. - /incoming
  672. - /.Trash*
  673. - /lost+found
  674. - /backup/device
  675. EOF
  676. #+end_src
  677. *** nextcloud
  678. **** Mise à jour en dernière version
  679. Cette commande permet d'appliquer successivement les version de
  680. nextcloud, elle modifie le =compose.yml=. Et installe la dernière
  681. version disponible donnée par =docker-tags-fetch docker.0k.io/nextcloud=.
  682. Étant donné que la commande est un peu nouvelle et la tâche assez
  683. fastidieuse et risquée, ne pas hésiter à la lancer dans un =tmux= pour
  684. être prêt à demander de l'aide. Également, lancer un =myc-update= avant.
  685. Aussi, il est toujours bon de vérifier que le backup fonctionne et que
  686. la version sur le serveur de backup est à jour (lancer =vps backup= est
  687. un bon moyen de voir cela).
  688. #+begin_src sh
  689. vps nextcloud upgrade
  690. #+end_src
  691. *** mongo
  692. **** Mise à jour en dernière version
  693. Cette commande permet d'appliquer successivement les version de
  694. mongo, elle modifie le =compose.yml=. Et installe la dernière
  695. version disponible donnée par =docker-tags-fetch docker.0k.io/mongo=.
  696. Étant donné que la commande est un peu nouvelle et la tâche assez
  697. fastidieuse et risquée, ne pas hésiter à la lancer dans un =tmux= pour
  698. être prêt à demander de l'aide. Également, lancer un =myc-update= avant.
  699. Aussi, il est toujours bon de vérifier que le backup fonctionne et que
  700. la version sur le serveur de backup est à jour (lancer =vps backup= est
  701. un bon moyen de voir cela).
  702. #+begin_src sh
  703. vps mongo upgrade
  704. #+end_src
  705. *** onlyoffice
  706. **** Troubleshooting
  707. Il y eu de nombreux cas où onlyoffice pète ses propres
  708. fichiers de config. Une bonne façon de le régler:
  709. #+begin_src sh
  710. docker stop myc_onlyoffice_1
  711. rm -rf /srv/datastore/config/onlyoffice
  712. compose --debug up
  713. #+end_src
  714. Ceci permet d'effacer la config mise en place par compose et de la
  715. reconstruire, et tout ce qui est dans
  716. `/srv/datastore/config/onlyoffice` se reconstruit tout seul via les
  717. charms au moment du `compose up`.
  718. * Interventions avancées
  719. Description des process avancés d'intervention sur une installation existante.
  720. ** Modification du compose
  721. Y a un exemple en commentaire dans le =/opt/apps/myc-deploy/compose.yml=
  722. Petit exemple:
  723. #+BEGIN_SRC yaml
  724. odoo:
  725. ...
  726. docker-compose:
  727. ## Important to keep as a list: otherwise it'll overwrite charm's arguments.
  728. command:
  729. - "--log-level=debug"
  730. environment:
  731. TOTO: TUTU
  732. image: masuperimage
  733. #+END_SRC
  734. ** Récupération de donnée
  735. *** Depuis le VPS backuppé
  736. Les VPS backuppés peuvent avoir besoin de récupérer les données
  737. archivées. Pour le moment, comme il n'y pas d'accès aux versions
  738. précédentes des backups, l'intérêt de cette fonctionnalité reste
  739. limité.
  740. **** Par répertoire
  741. Via la commande =vps=, l'action =recover-target= permet de recouvrir
  742. les données du service d'archivage (si celui-ci à été correctement
  743. installé avec les commandes spécifiée dans la [[*rsync-backup][section =rsync-backup=]]).
  744. Récupération d'un répertoire:
  745. #+begin_src sh
  746. vps recover-target "cron/" /tmp/cron
  747. #+end_src
  748. Cette commande va récupérer le contenu archivé dans "cron/" pour le mettre
  749. sur l'hôte courant dans "/tmp/cron".
  750. Il est possible de spécifier l'option =--dry-run= (ou =-n=) pour ne
  751. rien modifier et voir quels sont les actions qui seront menées.
  752. Attention à l'usage de cette commande, en effet le répertoire de
  753. destination peut-être entièrement modifié : cette commande effacera et
  754. modifiera le contenu du répertoire de destination.
  755. *** Depuis un hôte d'administration
  756. **** Récupération d'un VPS complet
  757. ***** Mailcow
  758. Depuis un hôte d'adminstration, et via la command =0km=, nous
  759. pouvons re-déployer un backup existant sur un nouveau VPS.
  760. #+begin_src sh
  761. 0km vps-backup recover myadmin@core-06.0k.io:10023#mail.mybackupedvps.com mynewvps.com
  762. #+end_src
  763. Attention, cela supprimera toute installation =mailcow= précédente
  764. (donnée comprise) sur le VPS de destination.
  765. ***** Compose
  766. La commande complète n'est pas implémentée, mais il s'agit surtout de faire un
  767. recover partiel:
  768. #+begin_src sh
  769. 0km vps-backup recover myadmin@core-06.0k.io:10023#mail.mybackupedvps.com:/ mynewvps.com:/srv/datastore/data
  770. #+end_src
  771. Puis de copier le fichier =/srv/datastore/data/compose.yml= sur =/opt/apps/myc-deploy/compose.yml=:
  772. #+begin_src sh
  773. cp /srv/datastore/data/compose.yml /opt/apps/myc-deploy/compose.yml
  774. #+end_src
  775. Puis s'occuper des bases de données:
  776. ****** récupération des bases postgres
  777. Dans le répertoire =/srv/datastore/data/postgres/var/backups/pg=
  778. Récupération des derniers dumps:
  779. #+begin_src sh
  780. compose --debug up postgres
  781. for dump in /srv/datastore/data/postgres/var/backups/pg; do
  782. pgm cp "$dump" postgres@"${dump%%.*}"
  783. done
  784. #+end_src
  785. ****** récupération des bases mongo
  786. Dans le répertoire =/srv/datastore/data/mongo/var/backups/mongo=
  787. #+begin_src sh
  788. compose --debug up mongo
  789. docker run -ti --rm \
  790. -v /srv/datastore/data/mongo/var/backups/mongo:/tmp/backups \
  791. -w /tmp/backups \
  792. --entrypoint mongorestore \
  793. --network myc_default \
  794. myc_mongo --host rs01/mongo /tmp/backups/
  795. #+end_src
  796. ****** Finalisation
  797. Tout devrait être bon.
  798. Un ~compose --debug up~ devrait faire l'affaire.
  799. **** Récupération partielle
  800. ***** Récupération d'un répertoire ou fichier précis
  801. Depuis un hôte d'administration, et via la command =0km=, nous pouvons
  802. récupérer un répertoire ou un fichier précis d'un backup existant sur
  803. un nouveau VPS.
  804. C'est la même commande que pour la récupération complète, on rajoute à
  805. la source un chemin et possible aussi à la destination.
  806. #+begin_src sh
  807. 0km vps-backup recover myadmin@core-06.0k.io:10023#mail.mybackupedvps.com:/mon/chemin mynewvps.com
  808. 0km vps-backup recover myadmin@core-06.0k.io:10023#mail.mybackupedvps.com:/mon/chemin mynewvps.com:/ma/dest
  809. #+end_src
  810. ***** Récupération d'un composant
  811. Suivant si le type de backup est reconnu et le supporte, il est
  812. possible de nommer un composant précis en lieu et place d'un
  813. répertoire ou d'un fichier.
  814. Par exemple, les backup de type 'mailcow' supportent les composants
  815. suivants: =mailcow=, =postfix=, =rspamd=, =redis=, =crypt=, =vmail=,
  816. =vmail-attachments=, =mysql=.
  817. #+begin_src sh
  818. 0km vps-backup recover myadmin@core-06.0k.io:10023#mail.mybackupedvps.com:mailcow,mysql mynewvps.com
  819. 0km vps-backup recover myadmin@core-06.0k.io:10023#mail.mybackupedvps.com:postfix mynewvps.com
  820. #+end_src
  821. ** Usage de l’alerting
  822. Une commande ~send~ est fourni pour envoyer des alertes via [[https://docs.ntfy.sh/][ntfy]], et
  823. par défaut, enverra ces notifications sur http://ntfy.0k.io .
  824. Par défaut, le VPS dispose d'un topic qui lui est propre (et surlequel
  825. il a les droits de publication). Et il est possible de rediriger les
  826. différent type de notification vers les topics que l'on souhaite pour
  827. permettre une administration de ces VPS.
  828. Donc, pour les admin, via la commande ~0km vps-subscribe~, on pourra
  829. facilement gérer l'addition de nouveau topic et en même temps
  830. s'assurer de donner les droit au VPS de publication sur ces topics.
  831. *** Commande ~send~
  832. Sur le VPS, la commande ~send~ permet d’envoyer un message sur un ou
  833. plusieurs topics. (voir ~send --help~ pour plus d’info). La fonction
  834. envoie un message sur un channel, et ce message est envoyé à tous les
  835. topics associés à ce channel.
  836. **** Configuration du serveur de notification
  837. La configuration du serveur de notification et les identifiant unique
  838. du VPS sont dans le fichier ~/etc/ntfy/ntfy.conf~.
  839. **** Configuration des topics
  840. La configuration des channels/topics est faite dans le fichier
  841. ~/etc/ntfy/topics.yml~.
  842. Exemple:
  843. - Configuration par défaut
  844. #+begin_src yaml
  845. .*\.(emerg|alert|crit|err|warning|notice):
  846. - ${LOGIN}_main
  847. #+end_src
  848. On pourra utiliser:
  849. #+begin_src sh
  850. send -c backup.crit "no backup done in 24h"
  851. #+end_src
  852. qui sera notifié sur le serveur =ntfy= de la configuration en cours, dans le
  853. topic ~${LOGIN}_main~. Ainsi que tout autre message dans les channels se terminant
  854. par ~.emerg~, ~.alert~, ... etc...
  855. - Configuration spécifique
  856. #+begin_src yaml
  857. .*\.alert:
  858. - elabore_alert
  859. #+end_src
  860. Si on **ajoute** la précédente configuration, la commande suivante:
  861. #+begin_src sh
  862. send -c disk.alert "no space left"
  863. #+end_src
  864. ... va envoyer le message aussi bien au précédent topic
  865. ~${LOGIN}_main~, mais aussi au topic ~elabore_alert~ car il se
  866. termine par ~.alert~.
  867. -
  868. #+begin_src yaml
  869. main:
  870. - maintenance
  871. - debug_foo
  872. - ${LOGIN}_main
  873. #+end_src
  874. La commande:
  875. #+begin_src sh
  876. send -c main "no space left"
  877. #+end_src
  878. .. enverra sur les topics ~maintenance~ et ~debug_foo~ et
  879. ~${LOGIN}_main~ (qui est un topic créé pour le VPS par défaut).
  880. *** Ajouter/Enlever des droits d’écriture sur les topics
  881. Sur un poste d'admin (via la commande ~0km~), et après avoir demandé
  882. un accès au serveur ntfy de destination (une clé SSH sera nécessaire),
  883. on pourra utiliser la sous-commande ~0km vps-subscribe~.
  884. #+begin_src sh
  885. ## Ajouter
  886. 0km vps-subscribe add CHANNEL TOPIC VPS
  887. ## Enlever
  888. 0km vps-subscribe rm CHANNEL TOPIC VPS
  889. #+end_src
  890. ** Troubleshooting
  891. S'il semble qu'il y a un soucis, il est possible de visualiser le
  892. =docker-compose.yml= qui est généré à la fin via l'ajout de =--debug=
  893. AVANT la commande:
  894. #+begin_src sh
  895. compose --debug up odoo frontend
  896. #+end_src
  897. *** en cas de soucis important ou inédit
  898. **** Lancer un ~compose --debug up~
  899. La simple action de relancer un ~compose --debug up~ permet à compose
  900. de repasser sur tous les scripts et notamment cela permet de recréer
  901. toutes les configurations, aussi certains des containers peuvent être
  902. également recréés et relancés. Notamment si de nouvelles images de
  903. services ont été ~pull~ récemment.
  904. #+begin_src sh
  905. compose --debug up
  906. #+end_src
  907. Si cette commande ne fonctionne pas, prendre le temps de bien lire le
  908. message d'erreur.
  909. **** Vider les cache de ~compose~
  910. En cas de problème non expliqués et inédits, il est bon de vérifier si
  911. l'effacement des caches de compose ne permet pas de corriger le
  912. problème :
  913. #+begin_src sh
  914. compose --debug cache clear
  915. #+end_src
  916. Puis relancer la commande qui ne fonctionne pas (par exemple ~compose
  917. --debug up~).
  918. **** Redémarrage du service =docker=
  919. Il y a de nombreux bugs répertoriés sur ~docker~ qui n'ont pas été
  920. réglés depuis de nombreuses années qui sont corrigés par un ~restart~ de
  921. tous les containers et du service docker lui-même.
  922. #+begin_src sh
  923. systemctl restart docker.service
  924. #+end_src
  925. va redémarrer le service docker sur la machine et donc tous les
  926. services gérés par docker (tous les services en somme).
  927. La coupure de service de cette commande est relativement courte
  928. (inférieure à la minute).
  929. **** Redéploiement des services
  930. Ce dernier cas est long, et n'est pas souvent efficace, mais il peut
  931. l'être dans certains cas. Cela va stopper et effacer tous les
  932. containers des services, puis reconstruire toute leur configuration et
  933. les relancer.
  934. Attention cela engendre une coupure de service qui peut être longue (le temps
  935. d'un ~compose up~ complet).
  936. #+begin_src sh
  937. compose --debug down &&
  938. compose --debug up
  939. #+end_src
  940. * Comment ça marche
  941. La surcouche =compose= a pour responsabilité de:
  942. - créer graduellement un =docker-compose.yml= et lancer =docker-compose=.
  943. - à partir des *charms* qui factorisent les parties réutilisables
  944. - et à partir du =compose.yml= qui offre une interface plus haut niveau
  945. et permet d'exprimer plus succintement les intentions de déploiement sans
  946. entrer dans la logique technique de l'implémentation des services.
  947. - lancer des executable et des instructions au fur et à mesure si nécessaire.
  948. Il part du =compose.yml= et accède aux définitions en yaml des charms
  949. à déployer et qui sont dans /srv/charms ... (qui en fait sont dans
  950. =/opt/apps/0k-charms=).
  951. Chaque charm possède une définition générale (le =metadata.yml=) qui
  952. permet également l'injection d'élément dans le =docker-compose.yml=
  953. final.
  954. Et puis il y a des =hooks= : des scripts bash lancés avec des
  955. information contextuelle dans des variables d'environment, et qui vont
  956. généralement mettre en place des services à l'initialisation ou pour
  957. s'assurer de la bonne liaison entre les services.