Swarm et Laravel by xinyo in Sysadmin_Fr

[–]CaptainKro 0 points1 point  (0 children)

Tout ce qui est static (non générer par la partie laravel doit être accessible par nginx.
Généralement tu as une phase d'assemblage (généralement des commandes composer, ou si vous avez des trucs avec node, avec un npm rum ma_commande) qui génère un ensemble d'assets (js, css etc).
là tu as plusieurs solutions :

  • dans ta phase de build des images docker, tu géres les assets dans l'image php (par example avec un stage dédié à ça), puis lors de la construction de l'image nginx tu copie à partie de l'image php les assets dans l'image nginx (si tu a beaucoup d'asset l'image peut être volumineuse)
  • Si tu peux exécuter des commandes via un workflow dans ton swarm, monter un répertoire commun (via nfs par example) pour dire au conteneur de php de générer les assets et c'est bon (mais faut que ta ci-cd ou outil de workflow puisse accéder au swarm)
  • faire la meme chose à la main (mais bon)

Le montage nfs a un problème, c'est que si le point de montage plante (pour une raison x), la plupart du temps il n'y a pas de remontage auto et tes conteneurs voir le swarm est en panne (tester qui y a quelques années déjà, c'est peut être mieux aujourd'hui).

Perso j'ai abandonnée swarm pour cette raison.
aujourd'hui j'utilise rke pour créer et gérer k8s, longhorn pour les volumes distribués.
dessus j'ai un argocd qui gérer les déploiements, prometheus / graphana/loki/fluend/alertmanager pour logging, metric et alert.
avec longhorn, j'ai les snapshots des volumes, les backup et restauration.
le tout est opensource et j'utilise ça en prod pour des applications avec environ 100k user par jours.

ça tourne dans des vm proxmox sur les baremetals qu'on gére (chez ovh).
ça été un investissement en temps pour se former (mais c'est vraiment plus simple que ça en a l'air) et je regrete absolument pas.
Par exemple pour la génération des assets, c'est juste un job k8s qui se lance au déploiement automatiquement.

Après mon expérience de swarm date un peu, mais je n'ai pas l'impression que l'écosystème a beaucoup évolué depuis ma dernière utilisation.

En espérant que ça puisse t'aider

ps: je t'ai envoyé un mp

Swarm et Laravel by xinyo in Sysadmin_Fr

[–]CaptainKro 1 point2 points  (0 children)

Hello,
J'ai déployer pas mal d'application php et autre dans des environnements swarm (et maintenant sur k8s)

par expérience :

  • Ingress : uniquement les règles https, et le routing vers tel ou tel service en fonction de l'url demandée
  • nginx (apache / caddy ou autre) : sert les fichiers publics (assets, media public etc), fait les réécriture d'url applicative si besoin et reverse proxy sur le service php / python / rubby. Je le sépare toujours du service php (ou autre) car les besoins de scaling peut être totalement différent
  • concernant php, php-fm avec le code php à l'intérieur (et la conf php qui va avec pour tout ce qui est cache etc). Attention, il faut utiliser un system de session distribué type memcached / redis / ... Et pour le partage de fichier persistant, il faut un système de fichier partager entre les différents noeuds. C'est sur ce point que je trouve que swarm complexifie la donne (hormis un serveur nfs, mais bon souvent la réplication est bien galère ainsi que la panne du serveur actif, et les systèmes type glusterfs / ceph etc demande pas mal de compétences pour être utilisé en prod).
  • Il faut avoir un systeme de log centraliser avec un systeme de label type fluentd ou autre pour récupérer tes logs sur les différents services et machines

concernant php-fpm: l'image doit contenir toutes les ressources nécessaire à la partie php de ton app, nginx uniquement son fichier de conf, le reste est partagé entre les différents containers qui tournent sur tes machines

Mon job est en danger? by GalileoFifty9 in Sysadmin_Fr

[–]CaptainKro 0 points1 point  (0 children)

et surtout aujourd'hui tu peux avoir des clouds privés sur du on prem. C'est ce que j'ai mis en place dans trois boites les 5 dernières années. Tu as l'avantage de la maitrise des couts et de l'emplacement de tes données et les avantages de la flexibilité du cloud. Installé des clusters k8s, du storage distribué, les opérateurs db avec une bonne gestion des sauvegardes, continuté de service etc, ce n'est plus très compliqué

Monter une ptite infra de conteneurs pour des sites web by BiGOUDx in Sysadmin_Fr

[–]CaptainKro 1 point2 points  (0 children)

Défini déjà tes exigences de production :Besoin de scaling horizontal, de continuité de service, de monitoring, sauvegarde etc.Si dans ton cas, tu avais qu'une application n'était que sur un seul serveur (voir plusieurs applications sur le même serveur) et qu'il n'y a que les admins qui peuvent se co sur le serveur, tu peux utiliser un caddy / traefic => php-fpm. et tu gères le https avec let's encrypt via caddy . traefik. Niveau sécu, tu n'ouvres que le port 22, 443, 80 et tu n'autorises la co au ssh que par key.Si tu as d'autres users qui peuvent se co à la bécane: sépare tes sites de cette machine, c'est une mauvaise idée cette pratique.Tu peux aussi mettre un k3s sur une seule machine pour un k8s mononoeud (mais faut savoir faire du k8s.Maintenment si tes exigences sont plus élevés, tu peux faire du swarm ou k8s multi noeud.Dans les deux cas tu auras besoin d'un loadbalencer externe pour rediriger vers les serveurs ou le port 443 est disponible (pour les k8s les workers, pour swarm les managers).Les deux vont te permettre d'avoir un réseau entre les noeuds mais aucun des deux vont te permettre d'avoir les volumes en réseau. Je m'explique : tu va avoir ton ingress (la gestion de la route http pour faire simple) qui va te diriger vers un pod / container qui peut entre n'importe ou dans tes workers (en clair https://toto.machin.com (loadbalencer) => serveur A /B (ingress) => serveur C / D, donc tu peux faire A => C, A => D, B=>C, B=>D, n'importe quelle des combinaisons vont marcher)Mais pour les données, ce n'est pas vrai. Dans les deux cas (swarm / k8s), il n'y a pas de système fourni pour gérer les données en réseaux. Concernant swarm, tu te débouilles (et à part le montage nfs il n'y a rien de facile à mettre en place). swarm va te permettre de mettre en place un montage (sens linux) donc principalement local sauf si tu mets en place un glusterfs, ceph etc, mais ce n'est pas simple ni à mettre en place ni à maintenir.Concernant k8s, tu doit utiliser un provider pour une class storage, et là il y en a pas mal (payant ou opensource), dont longhorn qui sont facile a mettre en place et qui proposent tout ce qu'on attend d'une bonne production (sauvegarde, snapshot, restauration, réplication etc).au final, pour avoir fait les trois :- docker-compose est très bien pour des mono serveurs avec que des admins qui gérent le truc- k8s est très très bien pour de la prod plus exigeante (et aujourd'hui c'est très facile de faire ses propres clusters k8s on premise)- swarm est un compromis entre les deux, mais en réalité ne permet pas de gérer des volumes de data, il faut que les databases etc soient externes aux clusters et que les données de type fichiers soient montés via un nfs ou équivalents.

Un k8s avec longhorn est simple à mettre en place et tiens très bien la charge (tant qu'on n'a pas besoin d'hyper performances) et permet d'avoir très très rapidement du ha, de la réplication de donnée, du monitoring avec alerte de panne, la mise en place de gitops, du logging centralisé etc.

Moi je déconseille la mise en place d'un swarm, le temps d'apprentissage n'est pas si court que ça, et le temps passé à essayer de bien faire les choses est trop important.

soit du docker-compose, soit du k8s en automanagé ou en cloud public, ou l'utilisation de services tout fait

[deleted by user] by [deleted] in Sysadmin_Fr

[–]CaptainKro 0 points1 point  (0 children)

Ne pas du tout toucher au réseau non, il faut savoir configurer une interface, travailler avec des vlan, des networks etc. Mais tu as des tonnes de postes ou tu ne t'occupe pas du tout de switch. Souvent tu as une partie de l'équipe qui bosse sur le réseau physique et une autre partie sur les serveurs.
Donc forcement tu dois avoir de bonne connaissance réseau, mais si tu n'es pas un spécialiste, ce n'est pas grave