Comment se déroule le déploiement vers la production à partir de l'environnement de développement VirtualBox / Vagrant local?
Récemment, j'ai commencé à lire sur la création d'environnements de développement avec un logiciel de virtualisation (je suis un débutant) et il semble que "l'infrastructure en tant que code" soit un concept vraiment puissant.
J'aime vraiment la structure de workflow décrite ici :
- La même image de base VirtualBox est utilisée autour de l'équipe
- Vagrant est utilisé pour "construire" et "fournir" rapidement une telle image à une configuration requise à l'aide de
- Recettes de chef (ou marionnette) qui est le seul morceau de code à mettre sous contrôle de version.
Cependant, je ne comprends toujours pas comment le code est transféré et déployé sur les serveurs de production.
Si je comprends bien, la façon courante de garder les environnements DEV et PROD identiques est de gérer l'instance de serveur de production comme une autre image virtuelle à provisionner avec Chef. Je peux avoir exactement le même système d'exploitation installé sur le serveur de production que moi (et l'équipe) utilise quotidiennement avec VirtualBox-Vagrant-Chef.
Mais le serveur de production peut avoir un matériel différent de celui du système d'exploitation invité virtuel, ce qui peut entraîner à nouveau des incohérences.
Alors, voici la question:
Quelle est la meilleure pratique connue et courante pour transférer et déployer du code sur un serveur de production à partir d'un environnement de développement géré avec la chaîne d'outils VirtualBox-Vagrant-Chef? Cette pratique permet-elle un déploiement continu?
[Modifier]: Remarque: Existe-t-il une pratique consistant à exécuter la même VM provisionnée avec Chef/Vagrant sur le serveur de production, comme cela est illustré sur ce diagramme ?
Je suis l'auteur de l'article que vous avez lié, donc mon 0.02
Si j'ai bien compris votre question, vous ne déplacez pas les vms du développement vers la production, vous créez un processus reproductible qui vous permet de créer le même état final (OS + config + app) encore et encore, peu importe où la destination est.
En utilisant vagrant, vous garantissez que vos développeurs utilisent le même système d'exploitation que vos serveurs de production, quel que soit le système d'exploitation qu'ils utilisent pour le développement.
En utilisant Puppet/Chef, vous garantissez que le système d'exploitation est configuré de la même manière, qu'il s'exécute dans une VM avec Vagrant, une VM en production, une VM dans le cloud ou du matériel nu. Il n'a pas besoin d'être virtuel.
Dans le cas de Puppet (le chef peut très probablement le faire aussi), vous pouvez créer le manifeste (recette) de telle sorte qu'ils se comportent différemment dans votre environnement vagabond, par ex.
if $::virtual != "virtualbox" { # not in vagrant
include sysctl_tuning
}
La question de la livraison continue est un peu trop large dans ce contexte. Je pense que la réponse serait "oui", pour ce que ça vaut.