Comment gérez-vous vos box EC2 Linux?

J'ai quelques images Linux EC2 qui effectuent des travaux de traitement de nuit pour l'un de mes projets. De temps en temps, je devrai entrer, apporter des modifications au code, configurer certaines choses et regrouper l'image.

Mon ensemble d'outils pour ces opérations est douloureusement clairsemé (SSH dans la boîte, modifier les fichiers dans VIM, les fichiers distants WGET dont j'ai besoin), et je soupçonne qu'il existe une bien meilleure façon de le faire. Je suis curieux de savoir ce que font les autres personnes dans ma position.

• Utilisez-vous une forme de système de fenêtrage et un équivalent de bureau à distance pour accéder à la boîte, ou s'agit-il uniquement d'une ligne de commande? La gestion des boîtes Windows EC2 est triviale, car vous pouvez simplement accéder au bureau à distance et transférer des fichiers sur le réseau. Y a-t-il un équivalent à cela dans le monde Linux?

• Faites-vous vos changements de configuration / réglages de script directement sur la machine? Ou avez-vous quelque chose de configuré sur votre box local pour modifier ces fichiers à distance? Ou les modifiez-vous simplement à distance puis les transférez-vous à chaque sauvegarde?

• Comment déplacez-vous les fichiers entre EC2 et votre environnement local? FTP? Une sorte de lecteur mappé via VPN?

J'aurais vraiment besoin de mettre en place quelques meilleures pratiques pour administrer ces boîtes. Toutes les suggestions pour éliminer une partie de la douleur seraient les bienvenues!

EDIT: Évidemment, je n'étais pas clair ci-dessus, car les deux premières réponses tournaient autour de la gestion et de la configuration des instances EC2. Je veux juste savoir comment déplacer le bureau à distance sur un serveur Linux en cours d'exécution pour que le déplacement et l'édition des fichiers soient moins pénibles.

Je ne fais plus beaucoup d'administration manuelle du système. Je considère mon infrastructure comme une entité programmable et la traite comme telle, en configurant des systèmes avec des outils qui automatisent la gestion de la configuration, la maintenance des nœuds EC2, etc. Outils dans ma boîte à outils:

• Ruby (mon langage de script / outil préféré)
• Git (contrôle de version)
• Chef d'Opscode (écrit en Ruby) (1)
• Capistrano (maintenance de masse ad hoc)
• Outils API EC2 d'Amazon pour la maintenance des instances et des images.
• Gemme AWS de Rightscale (liaisons Ruby pour EC2)

(1) - Divulgation, je travaille pour Opscode. D'autres outils remplissent cet espace comme la marionnette de Reductive Lab.

Je regroupe une AMI lorsque j'ai un nœud construit de la manière dont j'ai besoin pour une fonction spécifique. Par exemple, si je crée un serveur d'application Rails, j'obtiens tous les packages prérequis installés pour gagner du temps sur la construction.

Lorsque tout le reste échoue, je me connecte aux systèmes avec SSH. J'ai fait une administration manuelle du système pendant de nombreuses années, c'est un vieux chapeau.

Utilisez-vous une forme de système de fenêtrage et un équivalent de bureau à distance pour accéder à la boîte, ou s'agit-il uniquement d'une ligne de commande?

Je n'installe aucune interface graphique sur les serveurs, sauf si un package a une dépendance et que l'un est automatiquement installé.

Y a-t-il un équivalent à cela dans le monde Linux? (transfert de fichiers)

Je fais normalement deux types de transfert de fichiers / maintenance de fichiers.

• Installation du package
• Fichiers de configuration

Pour les packages natifs de la plateforme, j'utilise l'outil de gestion de packages standard comme APT ou YUM. Pour les installations sources (quelque chose.tar.gz), je télécharge généralement via wget.

Les fichiers de configuration sont généralement des modèles ERB gérés par Chef.

J'utilise SSH et SCP / SFTP pour transférer des fichiers manuellement.

Faites-vous vos changements de configuration / réglages de script directement sur la machine? Ou avez-vous quelque chose de configuré sur votre box local pour modifier ces fichiers à distance? Ou les modifiez-vous simplement à distance puis les transférez-vous à chaque sauvegarde?

Je garde tout ce qui concerne la gestion des systèmes dans un référentiel de contrôle logiciel. Voici mon flux de travail typique lors de la mise à jour de la configuration sur un ou plusieurs systèmes. Je pars de mon poste de travail local.

• Tirez du référentiel Git principal pour les modifications des autres.
• Modifier le ou les fichiers localement (comme mettre à jour un fichier de configuration).
• Validez le changement, poussez pour maîtriser.
• Sur le serveur Chef (connecté via SSH), tirez la dernière modification que je viens de valider.
• Déployez la configuration à l'endroit approprié sur le serveur Chef (j'utilise Rake pour cela).
• Les clients chefs s'exécutent sur un intervalle, donc ils prendront les changements toutes les 30 minutes. Si j'ai besoin de quelque chose immédiatement, je lance le chef-client manuellement.
• Vérifiez le changement!

Comment déplacez-vous les fichiers entre EC2 et votre environnement local? FTP? Une sorte de lecteur mappé via VPN?

Il existe quelques emplacements où les fichiers que j'utilise sur les nœuds EC2 peuvent être stockés.

• Serveur chef. Modèles de configuration principalement, quelques petits packages aussi.
• GitHub. Nous stockons notre code (projets open source) sur GitHub. Les nœuds EC2 peuvent y accéder facilement (comme pour une extraction de la dernière version de quelque chose).
• Godets Amazon S3. Certaines choses sont stockées dans un seau.

Je fais beaucoup de travail dans EC2, principalement en testant des environnements et des changements. En raison de mes outils et de mon flux de travail, je passe plus de temps à travailler sur des choses qui m'intéressent réellement et moins à traiter des fichiers individuels et à réfléchir à des configurations spécifiques.

Tous nos logiciels sont déployés via RPM. Chaque type d'instance EC2 est décrit par un fichier kickstart (qui répertorie les RPM à installer ...). La configuration kickstart signifie qu'une machine de travail de chaque type d'instance peut être construite à partir de zéro en environ 10 minutes.

Nous avons ensuite un programme qui appelle anaconda (le programme d'installation de Red Hat) pour prendre un fichier kickstart, installer le système dans un répertoire, puis regrouper le répertoire et le pousser vers S3 en tant qu'image Amazon Machine. Ce n'est qu'une étape, alors je tape juste:

kickstart2ami webserver.ks

Puisqu'une machine peut être complètement reconstruite, téléchargée et exécutée en environ 40 minutes, il est plus facile de créer de nouvelles images de machine que d'effectuer sysadmin sur les instances EC2 réelles (jetables). Par conséquent, aucun administrateur système n'est réellement exécuté sur les instances EC2.

J'aime NX pour l'accès à l'interface graphique à distance. Très bien documenté aussi.

J'utilise nautilus pour pas mal de gestion de fichiers et ssh pour les commandes. Il se branche directement sur votre système comme si vous y étiez physiquement dans le centre de données. Si vous le faites à partir d'une boîte Windows, ce type de connectivité ne fonctionnera pas car les vfs dans les fenêtres sont limités.

Je pense que vous n'avez pas besoin d'un bureau à distance pour ces tâches.

Comme d'autres l'ont mentionné, vous pouvez utiliser SFTP pour transférer les fichiers entre les boîtes. Utilisez le client WinSCP pour vous connecter via sftp, que vous pouvez également utiliser pour éditer les fichiers sur votre machine Windows (en double-cliquant dessus) comme si c'était sur votre machine locale. Vous pouvez également l'utiliser pour copier / déplacer des fichiers à distance.

Vous pouvez également envisager d'utiliser Midnight Commander (mc) sur la console ssh qui peut accélérer les opérations sur les fichiers. Pour installer, utilisez la commande yum install mcou apt-get install mc. Ensuite, vous pouvez le démarrer en tapant mcsur le terminal. Il dispose également d'une visionneuse et d'un éditeur intégrés plus simples que vim.

Si vous voulez vraiment avoir une interface graphique - que nous n'avons généralement pas sur les serveurs - vous devez installer l'environnement X et vous y connecter avec VNC. Dans de tels cas, nous nous connectons au serveur VNC via un tunnel ssh qui lui ajoute plus de sécurité.

En réponse à votre question sur la configuration d'un bureau distant avec X, si vous utilisez Debian, lisez ceci . Ce n'est pas exactement le meilleur document pour le configurer. Il vous fait installer beaucoup trop de paquets, mais il a la bonne idée. Vous n'avez vraiment besoin que d'un pilote vidéo factice pour X, puis que VNC démarre un bureau X.

Si vous utilisez ubuntu: nous envisageons d'utiliser paysage pour cela, c'est un produit commercial de l'équipe ubuntu (canonique) et sera intégré aux commandes ec2.

Vous pouvez essayer quelque chose comme capistrano, mais si cela ne suffit pas pour ce que vous recherchez, il semble que vous soyez un candidat pour une sorte de gestion de la configuration.
Puppet, reductivelabs.com/products/puppet/, se démarque vraiment dans ce domaine, mais peut être un peu exagéré pour vous, sauf si vous avez l'intention de devenir plus gros et que le travail acharné en vaut la peine.
Si vous utilisez l'une des distributions debian / ubuntu, alors je vérifierais les rôles
lâches. Cela a très peu d'apprentissage initial et fonctionne bien, mais à mesure que vous grandissez, cela peut devenir un peu lourd.