Un chef pour les gouverner tous

10

Je cherche chef pour automatiser les déploiements Magento - à la fois dans les options d'hébergement Magento standard ainsi que dans des environnements comme EC2. J'ai fait des recherches sur Google et je vois de nombreuses recettes, mais aucune ne me semble vraiment canonique. Y a-t-il un script de chef particulier qui est meilleur / meilleur? De plus, si vous avez déjà fait des déploiements de chef avec PHP, quelle est la chose que vous souhaiteriez savoir au début?

deploy Alan Storm
la source
2
J'aurais aimé savoir que Ansible ( ansible.com/home ) existait.
Reid Blomquist
Quelques autres alternatives si vous êtes intéressé, saltstack.com et docker.com . Les deux semblent prometteurs, mais je n'ai pas eu l'occasion de travailler avec l'un ou l'autre.
beeplogic
1
J'ai expérimenté avec capistrano-ash: github.com/augustash/capistrano-ash
pzirkind
Je pense que Reid est sur quelque chose, Alan re: Ansible. Il ne nécessite pas d'agent (fonctionne avec les clés ssh +) pour être installé sur les clients, c'est un système déclaratif donc il est idempotent et en général j'ai trouvé que son utilisation me laisse le "faire une chose, faites-le simplement, et faites-le bien "sentiment unix par rapport à des systèmes plus robustes comme le chef, la marionnette et le sel. Cela fait longtemps que vous n'avez pas posté cela à l'origine, des mises à jour sur vos pensées après avoir travaillé avec le chef un moment?
Bryan 'BJ' Hoffpauir Jr.

Réponses:

6

Il est presque impossible d'avoir un ensemble unique de routines. J'ai réussi à écrire un script Bash qui exécute des chef-clientexécutions sur des listes d'hôtes fournies par knife search. Les procédures ressemblent à ceci…

Open Source Chef Server 10.18.2 sur Ubuntu 12.04 LTS

  1. Initialiser les variables
  2. Obtenez le dernier hachage de révision de GitHub pour $branch
  3. Désactivez la surveillance de la disponibilité pour empêcher les alertes sur l'état HTTP 503
  4. Basculez tous les hôtes Web et utilitaires en mode maintenance
  5. Utilitaire de déploiement
    1. Arrêtez le cron de Magento et tous les travailleurs de Resque
    2. Adresse des dépendances du système de fichiers
    3. Chef extrait la révision définie en tant que nouvelle version
    4. Adresse les dépendances Magento (packages, modules, système de fichiers, autorisations)
    5. Mettre à jour toutes les tâches et scripts cron pour l'automatisation
    6. Déployer tous les modules (compositeur)
    7. Vider le cache avec n98-magerun.phar
    8. Exécutez toutes les migrations avec n98-magerun.phar
    9. Réactiver le cron Magento
    10. Démarrer Resque Workers
  6. Déployer le premier hébergeur Web
    1. Adresse des dépendances du système de fichiers
    2. Chef vérifie le défini $revisioncomme une nouvelle version
    3. Adresse des dépendances Magento
    4. Déployer tous les modules Magento
  7. Marquer un nouveau déploiement dans New Relic
  8. Activer les services de surveillance de la disponibilité
  9. Désactiver les services d'équilibrage de charge vers tous les autres hôtes Web
  10. Poursuivre les déploiements sur les hôtes Web, en les mettant en ligne de manière séquentielle
  11. Effectuer des routines Chef pour les hôtes de recherche

Source: https://gist.github.com/parhamr/6177160#file-2-deployment

parhamr
la source
4

C'est ainsi que j'ai abordé ce domaine en portant le rôle wys be admin / devops. La plupart des éléments suivants ne seront que des principes généraux que j'essaie de suivre et non spécifiques au chef.

J'ai fini par aller avec Puppet parce que j'ai trouvé qu'il y avait plus de ressources à l'époque et que je me sentais plus facile à ramasser pour moi.

J'ai regardé les différents modules pré-construits disponibles pour des choses comme apache, php5, etc. Beaucoup d'entre eux semblaient faire bien plus que ce dont j'avais besoin et étant si peu familier avec la plate-forme, je ne faisais pas confiance à ce qui se passait. J'ai décidé qu'il allait être plus simple pour moi d'identifier simplement ce que je devais faire sur chaque type de nœud.

J'ai démarré le processus en provisionnant l'environnement de développement local de l'équipe (vargrant + virtual box). Pour chaque service / composant j'ai créé un module: php5, apache2, redis, mysql, etc.

Une fois l'environnement de développement stable / fonctionnel, j'ai commencé à créer l'environnement QA. J'ai défini des types de nœuds génériques pour les serveurs Web, redis, vernis, etc. qui réutilisaient les mêmes modules que dev. Une fois cela fait, la mise en scène et la production avaient besoin de modifications minimes pour être opérationnel.

Au fur et à mesure que vous parcourez et écrivez vos recettes / modèles, vous devez réfléchir à la manière de les réutiliser / les généraliser. Ne codez pas des choses comme des chemins ou des utilisateurs / groupes qui pourraient changer entre les distributions / projets / environnements. Étant donné que vous envisagez une approche généralisée, je suppose qu'un grand obstacle résoudra les différences entre les distributions * nix.

Plus important encore, garder est simple. Automatisez / standardisez les parties les plus importantes / chronophages de l'environnement. Itérer, évoluer.

beeplogic
la source