Arch Linux est-il adapté à l'environnement serveur ?

Solution 1 :

Le plus gros problème avec Arch en tant que système d'exploitation pour serveur est probablement qu'il n'est pas clair où et quand les applications peuvent tomber en panne après une mise à niveau. Le plus souvent, vous devez vous tenir au courant de ce qui se passe sur le wiki et sur les forums avant d'effectuer toute sorte de mise à jour; avec Debian et CentOS, vous pouvez être assuré que les mises à niveau ne casseront aucune application, car le plus souvent, les mises à niveau effectuées sur la branche STABLE seront des correctifs de sécurité/bogues.

Solution 2 :

Bien que j'adore Arch, je ne l'utiliserais pas pour un environnement de production. Tout d'abord, dans un environnement de production, vous avez besoin de quelque chose de stable et bien testé. De plus, comme il est assez dépouillé, vous devez créer des scripts personnalisés ou configurer les choses manuellement (c'est parfois bien car vous savez exactement ce qui s'exécute sur votre système, mais très mauvais car cela prend trop de temps pour le configurer). De plus, comme il n'est pas très utilisé dans les environnements de production, en cas de problème, vous ne trouverez pas le support que vous trouveriez si vous utilisiez Debian ou Fedora (la communauté Arch est géniale, mais pour être honnête, elle n'est pas aussi grande comme Debian ou Fedora)

Pour résumer, je pense que c'est génial pour une utilisation sur ordinateur, mais pas pour les environnements de production

Solution 3 :

Oui.

Avantages :

système vraiment minimal prêt à l'emploi, idéal pour les performances, en particulier sur les machines/VPS bas de gamme. Aucun service inutile - par rapport à CentOS 7 qui a lancé plusieurs services liés aux machines virtuelles qui ne m'étaient même pas applicables car je fonctionnais sur du métal nu.
logiciels à jour et grands référentiels ; J'ai perdu pas mal de temps avec CentOS quand quelque chose n'était pas dans les repos et j'ai été obligé de le compiler à partir de la source ou d'installer des RPM/repos tiers, puis de me retrouver dans l'enfer des dépendances parce que ces RPM tiers étaient en conflit avec les mises à jour des dépôts officiels.
systemd, bien que d'autres distributions (même Ubuntu) y passent, donc c'est moins un pro mais quelque chose à attendre de toute distribution décente.
des outils de configuration réseau qui ont du sens. Pas de gestionnaire de réseau de niveau bureau ni de pare-feu (en regardant CentOS/RHEL).
gestionnaire de paquets qui fait exactement ce qu'il dit sur l'étain. Le gestionnaire de paquets n'essaiera pas de vous "aider" en configurant ou en démarrant automatiquement le service que vous venez d'installer (en regardant Ubuntu/Debian). C'est aussi rapide, mieux que yum , et peut-être un tout petit peu plus rapide que apt-get .
processus d'installation qui ne vous oblige pas à utiliser les valeurs par défaut et offre beaucoup de place pour la personnalisation - comparez cela à CentOS/RHEL qui vous oblige à utiliser LVM et à échanger, ce qui n'est pas toujours nécessaire (presque jamais dans mon cas en fait)
/usr/bin/python est en fait le dernier Python 3, pas le Python 2.7 préhistorique. C'est toujours un problème pour moi avec la plupart des autres distributions, et vous ne pouvez pas facilement changer cela non plus (du moins pas à l'échelle du système) car cela cassera de nombreuses applications qui en dépendent.

Inconvénients :

certaines mises à niveau nécessitent une intervention manuelle et peuvent casser. Je recommande d'avoir une réplique de votre environnement de production dans les machines virtuelles et de tester les mises à niveau avant de les déployer sur les vrais serveurs.
aucune configuration de travail par défaut. Mauvais pour les personnes qui veulent juste exécuter apt-get et installer leur pile LAMP non sécurisée par défaut pour déployer leur application PHP vulnérable merdique et polluer Internet. Bien sûr, c'est en fait un avantage pour les personnes sérieuses car cela vous oblige à revoir les fichiers de configuration avant de démarrer le service.
pas de prise en charge de SELinux. Il y a GRSecurity et son RBAC, mais vous aurez besoin de temps pour vous y habituer et l'affiner.

Je ne suis pas d'accord sur le fait que vous obtenez moins de soutien. Bien sûr, c'est vrai. Est-ce un inconvénient ? Non à mon avis. Il y a très peu de choses dans Arch qui pourraient casser et nécessiteront l'assistance d'une personne familière avec Arch. Habituellement, si vous avez besoin d'assistance, vous en aurez besoin pour un logiciel particulier, auquel cas vous demanderez à ses développeurs et le fait que vous utilisez Arch devient sans importance.

Pour moi, utiliser Arch est beaucoup plus facile et prend moins de temps que d'utiliser CentOS et son Networkmanager, firewalld et autres services inutiles (ils peuvent être désactivés, mais c'est déjà du temps perdu). De plus, je connais chaque service qui s'exécute sur le système parce que je l'aurais installé, pas de logiciel sournois qui me harcèle à propos d'un bogue et veut téléphoner à la maison même si je viens d'installer le système.

Solution 4 :

Je suggérerais toujours l'un des :

CentOS. C'est un clone RHEL gratuit, ce qui signifie que vous bénéficiez d'un cycle de support très long (7 ans), au cours duquel vous pouvez obtenir juste des correctifs de sécurité et des améliorations mineures, il est donc très, très facile de garder le système corrigé. En outre, de nombreux logiciels "commerciaux" ciblent RHEL, ils sont donc plus faciles à installer sur CentOS. Inconvénients :je préfère apt/dpkg à yum/rpm, pas facile d'y faire fonctionner un logiciel de pointe, sélection de logiciels quelque peu spartiate
Ubuntu LTS. En fait, je ne l'ai toujours pas utilisé, mais il a aussi un long cycle de support et c'est Debianish
Test Debian. Debian est ma distribution préférée, fonctionne très bien et propose une sélection de paquets stupidement énorme qui est très bien organisée. Le maintien des correctifs prend un peu plus de temps, mais il est plus facile d'installer des logiciels (c'est-à-dire qu'il y a plus de choses facilement empaquetées).

Je suggérerais aux pros d'utiliser Arch Linux pour l'un de ces trois et de voir si cela en vaut la peine.

Solution 5 :

J'utilise plusieurs serveurs Archlinux depuis 2013 dans un environnement de production et cela fonctionne à merveille.

Bien sûr, vous devez vous assurer que les mises à jour se passent bien en les exécutant souvent et en vérifiant toujours la page archlinux avant de mettre à niveau.

Mais c'est tout, au final vous aurez beaucoup plus de mal à mettre à jour RedHat/CentOS de 6 à 7 (presque impossible) ou SLES/SLED de 11 à 12 et ainsi de suite.

Vous avez constamment de petites mises à jour qui, de temps en temps, provoquent une action, mais je n'ai jamais eu quelque chose d'important au cours des 5 dernières années.

Et aussi vous êtes toujours à jour, s'il y a une fuite de sécurité dans le noyau, dans openssl, dans le bash ou autre, vous avez les mises à jour en quelques heures plutôt qu'en jours ou mois.

Mon serveur, par exemple, est entièrement mis à niveau et protégé contre le spectre v1, le spectre v2 et l'effondrement, je suis à peu près sûr que seulement 1 % des personnes qui publient ici ont des serveurs protégés contre les trois.

C'est rapide, c'est sûr, c'est stable (!) et vous avez un logiciel à jour qui vous soulage de beaucoup de problèmes.

Je peux fortement recommander d'utiliser Archlinux sur le serveur, le seul inconvénient est que vous devez savoir ce que vous faites. Vous devez avoir installé un système LFS au moins une fois afin de comprendre les bases de la construction et du fonctionnement d'une distribution Linux.

Le seul système de serveur que j'ai trouvé plus solide qu'Archlinux dans un environnement de serveur était Gentoo. Il y avait un système Gentoo sans mises à jour pendant 700 jours et 1 heure plus tard, ce système était à jour et fonctionnait avec le seul temps d'arrêt étant un redémarrage unique.

Mais d'autres systèmes comme Debian/Ubuntu, RedHat, SUSE vont tout gâcher complètement lors d'une mise à jour de la distribution. RedHat vous déconseille même activement de faire une mise à jour de la distribution et vous recommande de la réinstaller (selon la documentation officielle).

Alors oui, RedHat est plus stable qu'Archlinux, mais uniquement parce que vous n'obtenez pas de grosses mises à jour. Et quand vous les obtenez, vous êtes foutu.