Recommandations techniques et meilleures pratiques pour les didacticiels de DigitalOcean

Ce guide est un effort pour résumer les meilleures pratiques établies et les recommandations fortes pour les auteurs de tutoriels DigitalOcean. Il est destiné à fournir une base de cohérence, d’exactitude technique et de facilité d’utilisation dans le matériel pédagogique de DigitalOcean.

Il s'agit par nature à la fois d'un travail en cours et d'un document d'opinion, basé sur l'expérience croissante des rédacteurs et éditeurs techniques internes, des gestionnaires de communauté et des ingénieurs. Ses recommandations sont sujettes à modification et sont spécifiquement destinées à des contenus éducatifs destinés à un large éventail de lecteurs et d'utilisateurs finaux.

Les systèmes Ubuntu et Debian devraient avoirunattended-upgrades avec au moins des mises à jour de sécurité installées et configurées. Nous recommandons de ne pas redémarrer ou mettre à jour automatiquement tous, dans un contexte donné.

Nous recommandons généralementsudo apt-get dist-upgrade plutôt quesudo apt-get upgrade, en examinant de près les modifications proposées pour nous assurer que rien de destructeur ne passe. Les deux commandes sont très similaires, mais l'utilisation deupgrade peut être moins prévisible car certaines modifications sont retenues. Le fait de retenir certains packages peut entraîner des incohérences de version qui pourraient causer des problèmes avec les systèmes de production.
Nous continuerons à utiliserapt-get sur Ubuntu 16.04 en raison d'un manque de documentation pourapt et certains turbulence concernant le gestionnaire de paquets préféré de la distribution.

Veillez à utiliser les commandes système init natives, même lorsque des commandes de compatibilité héritées sont disponibles. Par exemple, utilisezsudo systemctl start [service_name] même sisudo service [service_name] start fonctionnera.

Fournissez des informations sur l'activation ou la désactivation du service à partir du démarrage. Indiquez comment inspecter le résultat des commandes liées au service lorsqu'elles ne sont pas clairement indiquées par l'interface (journalctl -u,systemctl status, etc.).

Préférer les redémarrages aux rechargements de services en règle générale. Dans la plupart des cas, il est plus important d’assurer un état connu que d’éviter une interruption de service d’une fraction de seconde. Les redémarrages sont également plus utiles en cas de défaillance complète du service.

À moins que cela ne fasse partie d’un flux de travail de gestion de la configuration, préférez les scripts de données utilisateur et les scripts cloudinit aux scripts bash de données utilisateur dans la plupart des cas.

Expliquez où et comment accéder aux journaux des services installés. Le cas échéant, expliquez les commandessystemctl etjournalctl pour vérifier l'état du service et la sortie du journal. Dans la mesure du possible, proposez des suggestions concises pour diagnostiquer les cas d'échec les plus courants.

Assurez-vous de gérer la rotation des journaux dans les cas où cela n’est pas géré par les packages ou d’autres mécanismes d’installation.

Pour les fichiers journaux en texte brut suivants, utiliseztail -F, pastail -f, car ce dernier ne suivra pas un fichier à travers les renommages et pourrait causer de la confusion si les journaux sont tournés pendant qu'un utilisateur les regarde.

Créez des utilisateurssudo au lieu d'utiliser directement root. Reportez-vous aux guides de configuration initiale du serveur appropriés qui expliquent cette tâche comme condition préalable.

Sur les distributions basées sur Debian, ajoutez et supprimez des utilisateurs avec respectivementadduser sammy etdeluser --remove-home sammy; sur les distributions basées sur RHEL, utilisezadduser sammy (définissez un mot de passe avecpasswd sammy si nécessaire) etuserdel -r sammy.

Accordez les privilègessudo avecusermod -aG sudo sammy sur Ubuntu. CentOS est un peu plus compliqué. Les versions modernes utilisentusermod -aG wheel sammy, mais certaines versions nécessitent quevisudo décommente d'abord les autorisations de groupe dewheel. Plus précisément, sur CentOS 5,sudo doit être installé et le groupewheel doit être décommenté avecvisudo; sur CentOS 6,sudo est déjà installé, maiswheel doit être décommenté; CentOS 7 asudo et le groupewheel est déjà configuré.

Lorsque vous utilisez des commandes avec privilège d'évaluation, veillez à les tester telles qu'elles sont écrites. Pour transmettre des variables d'environnement viasudo, utilisezsudo -E command_to_run (si approuvé avec tout l'environnement) ousudo FOO=BAR command_to_run. Pour les instances qui nécessitent un shell racine, utilisezsudo -i. Pour les instances nécessitant une redirection, utiliseztee -a pour ajouter plutôt que remplacer le fichier de destination:[sudo] command_to_run | sudo tee [-a] file_to_change.

Pour les shells interactifs, supposons Bash sur les systèmes GNU / Linux, mentionnés explicitement le cas échéant. Sous FreeBSD, utilisez tcsh, car il est disponible et contient des fonctionnalités utiles.

Pour les éditeurs de texte, nous incluons la copie «utiliser [préféré] ou votre éditeur de texte préféré», et nous incluons les éditeurs suivants pour les débutants dans les commandes destinées à ces copier-coller. Sous Linux, nous utilisons par défautnano; sur FreeBSD, nous utilisons par défautee. vi (m) est autorisé, mais évitez-le dans les rubriques introductives où il pourrait constituer une pierre d'achoppement pour les débutants.

Pour le transfert de fichiers, nous recommandons généralementsftp dans la plupart des cas pour ses utilisations interactives et scp, bien qu'il ne dispose pas de fonctionnalité push, doncscp est également acceptable. rsync est utile pour les sauvegardes et les transferts volumineux (ou de nombreux petits fichiers). N'utilisez en aucun cas le FTP. Nous nous efforçons également de standardiser surcurl surwget en raison de sa robustesse. L'avantage dewget est principalement le téléchargement récursif (i.e. un cas d'utilisation spécial qui n'est pas commun pour notre type de contenu).

Sur les machines livrées avec les utilitairesiproute2, nous les préférons à la suitenet-tools, qui estconsidered obsolete. En général, les utilitaires deiproute2 commess auront un meilleur support pour plusieurs interfaces, IPv6, les nouvelles fonctionnalités du noyau, etc. De même, nous devrions utiliserip route surroute,ip addr show surifconfig, etc. Parfois, la sortie des anciens utilitaires est un peu plus propre par défaut, mais la sortie elle-même est un peu moins fiable, car ils ne gèrent pas aussi les cas marginaux. Lorsque cela est possible, nous contrôlerons la sortie plus détaillée en utilisant les indicateurs disponibles.

Dans le contexte des didacticiels d'administration des systèmes, évitez généralement les longs scripts personnalisés et les scripts shell longs.

Les scripts rédigés par les auteurs (et éventuellement d’autres ressources) doivent résider dans un référentiel par article du compte GitHub de la communauté do, avec un lien vers le didacticiel publié. Suivez les bonnes pratiques de script en général. Par exemple, mettez toutes les variables que l'utilisateur devra renseigner en haut du script, de préférence dans une section bien marquée. Veillez également à commenter assidûment; le corps d’un script inséré dans un didacticiel DO ne doit pas fonctionner comme une boîte noire. Les utilisateurs devraient pouvoir trouver le sens en le lisant.

Préférez/bin/sh àbash et évitez les fonctionnalités spécifiques à Bash lorsque la portabilité ou la réutilisation multiplateforme sont un problème. Utilisez le shell et coreutils / les outils Unix standard pour les petites tâches; évitez d'introduire de nouvelles dépendances uniquement pour les tâches liées au langage collé, sauf si les avantages sont substantiels. Préférez#!/usr/bin/env interpreter à#!/path/to/interpreter.

En général, utilisezcron pour planifier des tâches récurrentes, mais les minuteries systemd sont également acceptables.

Lors du téléchargement de scripts ou de données, assurez-vous que l'utilisateur se trouve dans un répertoire inscriptible ou que les chemins d'accès sont spécifiés explicitement. Pour les fichiers qui doivent être disponibles pour référence ou réutilisation, utilisez le répertoire personnel de l'utilisateur, à moins qu'ils n'appartiennent à un chemin standard bien défini ailleurs sur le système de fichiers (comme/opt ou/etc). Pour les fichiers jetables, utilisez/tmp.

Nous recommandons les répertoires de configuration de style Debian pour les distributions qui ne le structurent pas de cette façon par défaut. Testez toujours les modifications de configuration (Apache utilisesudo apachectl configtest et Nginx utilisesudo nginx -t).
/var/www/html doit être utilisé comme racine de document pour tous les serveurs Web. La valeur par défaut de/usr/share/nginx/htmlde Nginx doit être modifiée car ce répertoire appartient à et peut potentiellement être modifié par les mises à jour du package. Ceci n’est plus un problème dans Ubuntu 16.04, mais restera pertinent pour les versions précédentes.

Pour aller de l'avant, préférez créer de nouveaux fichiers d'hôte virtuel Apache ou de fichiers de blocage de serveur Nginx plutôt que de modifier les fichiers par défaut fournis. Cela permet d'éviter certaines erreurs courantes et maintient les fichiers par défaut comme configuration de secours comme prévu.

Cryptez et authentifiez toutes les connexions entre les systèmes. N'encouragez pas les utilisateurs (explicitement ou implicitement) à envoyer des informations d'identification ou à transmettre des données non publiques en clair.

Plus précisément, les mots de passe et les clés ne doivent pas être transmis via des connexions non sécurisées. Les connexions à la base de données, la journalisation, la gestion des clusters et autres services doivent idéalement être chiffrés à tout moment. Les panneaux de contrôle Web doivent êtreserved over HTTPS connections et TLS / SSL doit être utilisé pour les services où il est pris en charge. Les services destinés au public tels que le simple HTTP sont autorisés, car les utilisateurs peuvent toujours vouloir ou avoir besoin de les offrir, mais devraient être fortement découragés dans le cas général, en particulier pour le contenu dynamique.

Évitez les pratiques qui constituent une sécurité peu rentable par l'obscurité ou la théâtralité, telles que la modification du port SSH par défaut. Ne configurez un pare-feu. Nos recommandations spécifiques à la distribution sontufw pour Ubuntu,iptables pour Debian etfirewalld pour CentOS. Cependant,iptables est plus cohérent sur toutes les plates-formes et possède de nombreux outils qui s'y connectent.

Il s’agit par nature d’un document évolutif, qui sera mis à jour souvent. Les technologies évoluent rapidement et DigitalOcean fait de son mieux pour rester à la hauteur, mais si vous constatez des erreurs ou si vous avez des commentaires, nous surveillerons les commentaires ci-dessous.