Forum Linux.debian/ubuntu Serveur : apt upgrade & vlogger

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
5
7
avr.
2018

Salut les devops,

J'ai deux questions qui se posent à moi : ;-)

  1. est-ce que vous utilisez vlogger ou bien la config standard vous convient ?
  2. comment faites vous pour gérer vos mises à jour logicielles (apt upgrade) sur vos serveurs :
  • vous utilisez un logiciel d'automation (Ansible, Chef, Pupet, Rudder, Salt etc) … mais du coup, on se sait pas ce qui se passe (tout du moins avec Ansible) ?
  • Vous utilisez un autre outil ?
  • Vous avez développé des scripts maison ?
  • Vous vous connectez en ssh et vous le faites à la main ?

Merci d'avance pour vos retours d'expérience.

  • # alors

    Posté par  . Évalué à 4. Dernière modification le 07 avril 2018 à 19:49.

    est-ce que vous utilisez vlogger ou bien la config standard vous convient ?

    Connait pas vlogger donc la config standard.

    vous utilisez un logiciel d'automation (Ansible, Chef, Pupet, Rudder, Salt etc) … mais du coup, on se sait pas ce qui se passe (tout du moins avec Ansible) ?

    J'utilise Puppet. J'ai configuré Puppet pour que la mise à jour se fasse avant chaque lancement de Puppet.

    Vous utilisez un autre outil ?

    J'utilise clustershell si je veux que les mises à jours se fassent plus rapidement par exemple. J'utilise etckeeper avec un serveur git pour backupper la configuration des serveurs.

    Vous avez développé des scripts maison ?

    Pourquoi perdre à réinventer la roue.

    Sinon pour éviter de mettre à jour des paquets qui ont des régressions, j'ai un miroir du dépôt officiel. Je fais des Snapshots de temps en temps. Et j'ai 3 rangs qui sont mis à jour progressivement : test pré-production et production qui permettent de limiter les régressions.

  • # Réponses

    Posté par  (site web personnel) . Évalué à 5.

    est-ce que vous utilisez vlogger ou bien la config standard vous convient ?

    Je n'utilise pas vlogger, mais je ne suis pas dans la cible gestion de multiples vhosts.

    comment faites vous pour gérer vos mises à jour logicielles (apt upgrade) sur vos serveurs :

    Ansible (professionnellement, avec un rôle pour gérer ça) / ssh (perso/associatif)

    mais du coup, on se sait pas ce qui se passe (tout du moins avec Ansible) ?

    Autant qu'en utilisant apt qui va lui même utiliser dpkg qui va lui même… etc. La délégation des tâches n'empêche pas le contrôle et ne doit pas dispenser de tests et de vérifications. Sur une prod, on ne devrait pas faire des apt upgrade sans avoir testé par ailleurs au préalable.

  • # Réponses^2

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 08 avril 2018 à 00:18.

    J'ai du pro et de l'associatif à ma charge :

    • Connait pas vlogger.
    • Généralement, les MàJs de mes serveurs sont pas dans le scope de la gestion de configuration. Je le fais régulièrement à mesure que je repasse sur les serveurs ou bien quand les uptime deviennent assez gros.
    • J'ai utilisé Puppet, Ansible et Salt. Ansible est pratique dans des environnements avec un gros passé, c'est pas super intrusif. Dans mon archi associative, j'utilise Salt. Et comme mon voisin du dessus, je maîtrise aussi bien Salt/Ansible que les divers processus de mes serveurs.
    • Le moins possible de scripts maison, mais quelques uns pour gérer des trucs qui marchent moyen avec Salt/Ansible. Des bootstraps compliqués, quelques tâches planifiées etc… je limite au max tout de même.
    • Je comprends pas entièrement la question sur SSH. J'ai la chance/malchance de pas devoir gérer 1000 serveurs ou d'avoir une infra sous Kubernetes avec plein de petits conteneurs. Je suis dans l'entre-deux, normalement j'ai pas besoin de me connecter aux serveurs pour les déploiments/màj de configuration. Salt/Ansible fait le taf à ma place. J'ai en revanche rarement des infras suffisamment rodées pour que les serveurs tournent tout seul. Donc SSH pour consultation des traces systèmes/logs très régulièrement. Plus rarement, des modifications systèmes que je m'efforce de remettre dans la gestion de conf le plus vite possible (généralement dès que le résultat attendu est en place).

  • # cron-apt

    Posté par  . Évalué à 3.

    Sur les serveurs, j'ai cron-apt qui installe automatiquement les mises à jour de sécurité. Pour les autres, je fais ça moi-même.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # unattended-upgrade + scripts de deploiement

    Posté par  (Mastodon) . Évalué à 2.

    Salut,

    Je suis fonctionnaire territorial et développeur web.

    J'administre au quotidien 4 serveurs debian, qui eux-même servent 4/5 applis web chacun, LAN ou Internet, essentiellement du django.

    Le "cœur" de mon activité est le dév web + déploiement (django), je propose par ailleurs quelques applications "utilitaires" à mes collègues : LimeSurvey, GitLab (pour moi et pour que mes collègues me mettent des tickets), Phraseanet (photothèque)…

    Pour les applis "utilitaires", rien à faire: sauvegardes automatisées, mises à jour à la main de temps en temps (pas trop quand même).

    Pour mes applications django:

    • J'ai des scripts de déploiement pour les service systemd : gunicorn + celery (si besoins), conf apache des virtualhosts
    • L'utilise unattended-upgrade pour les mises à jour des serveurs (base quotidienne), ça marche très bien : je n'ai rien à faire…
    • J'ai des log access / error pour chaque application django, dans un répertoire /var/www/www.example.tld/var/log, et des règles logrotate qui vont bien, sur une base quotidienne aussi.

    Mon infra peut être sans doute vue comme est assez sommaire, mais je suis tout seul là où je suis, et je ne peux guère compter sur mes collègues "Informatique": je travaille dans une direction de la communication, et je suis la seule personne "concernée" par ces services. Et comme je suis tout seul, si ça tombe quand je suis en congés ou en week-end, bah tant pis: je dors bien la nuit (après, c'est jamais arrivé… je dois avoir de la chance).

    J'ai fait le migration de mod_wsgi / (intégré) apache > gunicorn | (pipé) apache il y a 3/4 mois, et ça tourne bien, c'est là que j'ai fait le base de mes scripts de déploiement (je voulais pouvoir modifier simplement les .service / .conf des services systemd). Je souhaitais utiliser différentes versions de python selon les applis, et je n'ai pas été convaincu par mod_wsgi comme module python.

    J'ai regardé les différentes solutions de déploiement comme Salt ou Ansible, mais je penses (sans doutes à tord) que c'est overkill par rapport à mon activité. Je fait "un peu" de docker pour mes tâches CI dans gitlab. Les scripts de déploiement sont standardisés, et copiés / collés d'appli en appli.

    Courage !

  • # Oups

    Posté par  . Évalué à 0.

    J'ai cliqué par erreur sur « inutile ». Le note est revenue à zéro.

    • [^] # Re: Oups

      Posté par  . Évalué à 1.

      j'ai compensé en votant 'utile'

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.