Ansible vs Puppet

Ansible et Puppet sont les systèmes de gestion de configuration (SCM) nécessaires pour construire des infrastructures répétitives.

Ansible est facile à utiliser, possède une architecture sans agent (ne nécessite pas l'installation d'un agent / client sur le système cible) et une DSL de type YAML, écrite en Python et facilement étendue par modules. Gère généralement les configurations Linux.

Puppet a une architecture client-serveur (interroge périodiquement le serveur pour apporter des modifications à la configuration effectuée par l'administrateur réseau), est écrit en Ruby et possède une DSL de type Ruby. Cette application vous permet de gérer de manière centralisée la configuration des logiciels installés sur plusieurs ordinateurs.

L'article compare les avantages et les inconvénients de ces SCM.



Par rapport aux années 90, les administrateurs système et les développeurs doivent aujourd'hui gérer un nombre beaucoup plus important de serveurs qui hébergent beaucoup plus d'applications. La raison en est la croissance exponentielle de l'informatique pour les organisations et les entreprises associée à l'avènement de nouvelles technologies telles que la virtualisation et le cloud computing.

Ainsi, des outils tels que Puppet et Ansible deviennent rapidement des composants nécessaires à la gestion d'un grand nombre de serveurs, par exemple dans les centres de données. Ils s'appellent Configuration Management Tools (CM) et Remote Execution (RE) et sont souvent utilisés avec des outils de mise à jour logicielle. Ces applications utiles permettent, par exemple, à un administrateur réseau d'effectuer simultanément des actions sur plusieurs serveurs, de déployer plusieurs applications en un seul clic, ce qui simplifie considérablement la configuration et la maintenance de dizaines, centaines voire milliers de serveurs.

Ansible vs Puppet: un bref examen


Puppet est l'une des marques les plus connues du marché CM. Il existe depuis 2005, ce qui pour les outils CM équivaut à l'existence depuis la création de l'humanité. De nombreux grands noms tels que Google, Reddit, Dell, PayPal, Oracle, Los Alamos Labs et Stanford University gèrent leurs centres de données avec Puppet. Avoir de tels clients à bord donne toujours au produit un certain niveau de confiance. Puppet possède également l'interface la plus mature et fonctionne sur tous les principaux systèmes d'exploitation - Linux, Windows, Unix et même Mac OS X. Suivant le modèle créé par différentes versions de Linux, cette application open source est développée en Ruby. Cependant, il existe une société de support et de parrainage PuppetLabs solide et bien établie,offrant un support professionnel et une version commerciale commerciale du logiciel.

Puppet propose également une procédure d'installation simple et plusieurs outils pour des tâches telles que le déploiement rapide sur des serveurs clients. En plus de l'interface graphique, il existe une CLI basée sur Ruby. En fait, pour les tâches les plus avancées, vous devrez probablement dépendre de la CLI, et l'interface graphique est l'interface de visualisation, de gestion et de surveillance. Cela signifie qu'en plus de travailler en tant qu'administrateur système, vous devrez apprendre Ruby.



Vous pourriez penser: «Tout cela sonne bien! Y a-t-il des inconvénients, ou vaut-il la peine d'acheter Puppet en ce moment? ». Le débat sur l'utilisation de ce SCM sur les forums spécialisés CM est que Puppet, comme de nombreux autres géants du logiciel, a été victime de son succès et de sa taille. «Agile» et «agile» ne sont pas des mots qui peuvent être utilisés pour décrire le travail de Puppet. Les utilisateurs signalent des bogues qui prennent trop de temps pour corriger et ignorer les nouvelles demandes. Il y a aussi une certaine insatisfaction face au fait que PuppetLabs pousse constamment ses clients à accepter la version commerciale. Enfin, bien que Puppet prenne en charge à la fois Ruby pur et son DSL configuré sur la CLI, la prise en charge de Ruby seul est déconseillée. Ce sont de mauvaises nouvelles pour ceux qui n'ont étudié que Ruby, pas DSL.

Ansible a contourné Puppet, capturant la plus grande part de marché de l'industrie de la gestion de configuration - 26,5%. Il est suivi par Microsoft System Center CM (21,8%) et Puppet (12%).



C'est également un produit open source qui a été lancé en 2012 et a depuis été pris en charge par AnsibleWorks. Il a été développé en Python plutôt qu'en Ruby, ce qui le rend spirituellement plus proche de Salt (un autre nouvel outil CM) que Puppet. Un autre avantage de Python est qu'il est intégré à la plupart des applications Unix et Linux, donc SCM écrit dans ce langage s'installe et fonctionne plus rapidement.

Le stratagème marketing unique d'Ansible réside dans son déploiement facile et rapide. En fait, ce système n'utilise même pas d'agents déployés pour communiquer avec le client maître; à la place, toutes les fonctions sont exécutées via SSH. Pour les configurations qui ne prennent pas en charge SSH root, Ansible peut exécuter «sudo» en tant que root. Ansible peut être lancé à partir de la CLI sans utiliser de fichiers de configuration pour des tâches simples, telles que la vérification du fonctionnement du service ou le démarrage de mises à jour et de redémarrages. Pour les tâches plus complexes, la configuration Ansible est gérée à l'aide de la syntaxe YAML dans les fichiers de configuration appelés «playbooks». Les commandes ansible peuvent être écrites dans presque n'importe quel langage de programmation et distribuées sous forme de modules JSON universels, ce qui est clairement un avantage par rapport au choix d'un langage spécifique.

Ansible est devenu plus populaire avec une nouvelle approche des tâches de configuration traditionnelles, et de nombreuses entreprises l'utilisent pour déployer de grands centres de données.

La communauté des passionnés d'Ansible travaille dur pour tirer parti de son succès en augmentant le nombre d'appareils pris en charge, en intégrant une meilleure prise en charge de Windows, en améliorant l'écosystème, etc.

Ansible vs Puppet: différence d'installation


Les différences entre Ansible ou Puppet deviennent apparentes à partir du moment où les systèmes sont installés. Puisqu'ils suivent différents paradigmes architecturaux, leur cadre est sensiblement différent. Ainsi, Ansible a pour objectif explicite de rendre le processus de configuration aussi simple que possible, ce qui se reflète dans l'expérience utilisateur.



Pour configurer Ansible, vous devez d'abord désigner un nœud comme nœud de contrôle. En fait, n'importe lequel de vos nœuds peut être un nœud de gestion. Vous pouvez installer Ansible sur ce nœud en utilisant le dernier package Ansible à partir des référentiels de packages de votre distribution, sans avoir besoin de configurer le logiciel client sur d'autres nœuds. Créez simplement une paire de clés SSH sur votre nœud de gestion, puis copiez-les sur les autres nœuds. Ensuite, créez un fichier d'inventaire pour les nœuds Ansible - généralement sur les systèmes d'exploitation Linux comme Red Hat Linux, Ubuntu et Debian, cela se produit dans / etc / ansible / hosts. Vous êtes maintenant prêt à utiliser Ansible pour lancer le PlayBook sur votre hôte et le reste de l'infrastructure réseau.Ansible utilisera les connexions SSH avec votre nœud de contrôle pour déclencher la gestion de la configuration basée sur PlayBook.

La configuration de Puppet semble un peu plus compliquée, mais il y a beaucoup de documentation sur Internet qui vous aidera dans un cas difficile. Tout d'abord, vous devrez configurer les nœuds maître et agent afin qu'ils aient le même fuseau horaire et le même fuseau horaire. Ensuite, vous devez vous rendre sur le serveur maître avec les privilèges root et installer le logiciel serveur Puppet. Ensuite, vous devez configurer le fichier / etc / hosts de l'assistant Puppet pour connecter tous les clients gérés, démarrer le service PuppetServer et le mettre en mode «enable» pour recevoir les connexions client sur le port 8140. Comme Puppet s'appuie sur le logiciel client, vous devrez installer les agents logiciels Puppet sur chacun d'eux.

De plus, vous devrez ajouter l'adresse IP du serveur maître dans / etc / hosts pour que le client puisse s'y connecter. Pour ce faire, vous devez démarrer et activer le service d'agent Puppet sur chaque client, puis générer des certificats SSL, car ce système CM utilise HTTPS pour la communication client maître.

Dans les deux cas, il sera nécessaire de renforcer la sécurité du serveur pour exclure la possibilité de connexions non autorisées.

Ansible vs Puppet: évolutivité et mécanisme de transport de configuration


Les deux SCM évoluent bien, mais utilisent des mécanismes de transport de configuration différents pour y parvenir. En fait, que vous ayez besoin de gérer plusieurs centaines ou dizaines de milliers de nœuds, il existe des astuces et des stratégies que vous pouvez utiliser sur chaque plate-forme pour évoluer facilement au niveau souhaité.



Ansible utilise le mécanisme de transport intelligent par défaut, qui est basé sur des certificats SSH approuvés. Ansible analysera d'abord les PlayBooks et identifiera les éléments d'infrastructure affectés. Elle ouvrira ensuite une connexion SSH et créera un répertoire temporaire. Après avoir fermé cette connexion, Ansible ouvre une deuxième connexion pour copier le code du module Ansible et le code du modèle Ansible. Ansible fermera cette connexion avant d'ouvrir la troisième connexion finale pour exécuter le code. Ce paramètre répond à la plupart des besoins, mais il peut être modifié à mesure que l'infrastructure évolue.

La première fonction qu'Ansible peut utiliser est appelée ControlPersist, et elle s'appuie sur des sockets persistants et persistants pour réduire le temps nécessaire pour échanger des poignées de main qui sont nécessaires pour plusieurs connexions. Ansible prend également en charge le pipelining, une configuration qui réduit le nombre de connexions requises de trois à un. Enfin, Ansible peut être configuré pour gérer plus de nœuds d'inventaire en même temps en configurant la variable forks dans la configuration de ce système. Par défaut, cette valeur est 5, mais vous pouvez définir une valeur plus élevée pour accélérer le traitement.



Le mécanisme de transport Puppet est HTTPS, qui est géré à l'aide de certificats SSL. Un serveur Puppet gère les demandes de configuration pour une liste complète de clients Puppet. Chaque client envoie des faits Puppet au serveur maître avec une demande au répertoire Puppet, après quoi le serveur maître envoie ce répertoire en réponse. Le client traite ensuite l'annuaire, vérifiant chaque ressource logicielle avec l'état de configuration requis spécifié dans l'annuaire. Si la ressource n'est pas dans l'état souhaité, le client Puppet mettra à jour la ressource sur cet ordinateur et, une fois la mise à jour terminée, enverra un rapport sur la modification de configuration terminée au serveur Puppet.



Notamment, le modèle de traitement Puppet alloue un thread JRuby du pool de threads pour gérer chaque connexion cliente entrante. À mesure que le nombre de nœuds augmente, la mise à l'échelle de Puppet peut être optimisée en augmentant le nombre de threads JRuby disponibles dans le pool. Cela peut être fait en définissant le paramètre de configuration Puppet «max-active-instances» plus haut que la valeur par défaut, qui est 1. En règle générale, cette valeur est supposée être égale au nombre de cœurs de processeur de votre ordinateur, mais gardez à l'esprit que cela nécessitera plus Mémoire CPU utilisée RAM RAM. En règle générale, vous devrez également définir une «taille de segment de mémoire maximale» supérieure pour la machine virtuelle Java de votre serveur Puppet pour garantirque vos threads JRuby supplémentaires peuvent être alloués sans erreur Java de mémoire insuffisante. La prudence est requise lors de ce réglage, car cela peut entraîner une perte de performances.

Exemple de code CM Ansible


Pour le travail de configuration de tous les jours, l'écriture de code Ansible est étonnamment simple en raison de la combinaison de deux facteurs: l'utilisation du format YAML pour PlayBooks et le style déclaratif de gestion de configuration qui coupe les «coins vifs». Ceci est important pour améliorer rapidement les performances des commandes DevOps et garantir que votre code est gérable même pour des tâches de configuration complexes.

Le code ansible est idempotent. Cela signifie que vous pouvez exécuter PlayBook pour les composants du système en toute sécurité sans interruption et sans gâcher vos serveurs. Ansible ne modifiera que la configuration des ressources logicielles sur les serveurs où elle se trouve en dehors de l'état souhaité. Par exemple, si votre PlayBook doit installer un package et créer un fichier de configuration spécifique sur le disque, Ansible n'installera que ce package et créera le fichier de configuration spécifié lors du premier lancement du PlayBook sur l'hôte. Les lancements ultérieurs du PlayBook laissent automatiquement le package intact jusqu'à ce qu'il y ait un changement qui supprime ou modifie la configuration de fichier ou de package spécifiée. Cela maintient vos nœuds dans un état déterministe prévisible avec très peu ou pas de chance de dérive de configuration.

Voici un exemple de code Ansible PlayBook qui installe le serveur Web Tomcat sur vos sites. Cet exemple est tiré du référentiel d' exemples Ansible officiel , que vous devriez parcourir pour mieux vous familiariser avec le style idiomatique Ansible:

---
- name: Install Java 1.7
yum: name=java-1.7.0-openjdk state=present

- name: add group "tomcat"
group: name=tomcat

- name: add user "tomcat"
user: name=tomcat group=tomcat home=/usr/share/tomcat createhome=no
become: True
become_method: sudo

- name: Download Tomcat
get_url: url=http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.61/bin/apache-tomcat-7.0.61.tar.gz dest=/opt/apache-tomcat-7.0.61.tar.gz

- name: Extract archive
command: chdir=/usr/share /bin/tar xvf /opt/apache-tomcat-7.0.61.tar.gz -C /opt/ creates=/opt/apache-tomcat-7.0.61

- name: Symlink install directory
file: src=/opt/apache-tomcat-7.0.61 path=/usr/share/tomcat state=link

- name: Change ownership of Tomcat installation
file: path=/usr/share/tomcat/ owner=tomcat group=tomcat state=directory recurse=yes

- name: Configure Tomcat server
template: src=server.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat

- name: Configure Tomcat users
template: src=tomcat-users.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat

- name: Install Tomcat init script
copy: src=tomcat-initscript.sh dest=/etc/init.d/tomcat mode=0755

- name: Start Tomcat
service: name=tomcat state=started enabled=yes

- name: deploy iptables rules
template: src=iptables-save dest=/etc/sysconfig/iptables
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '6'"
notify: restart iptables

- name: insert firewalld rule for tomcat http port
firewalld: port=/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"

- name: insert firewalld rule for tomcat https port
firewalld: port=/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"

- name: wait for tomcat to start
wait_for: port=

Cette tâche Ansible spécifique télécharge et installe Apache Tomcat avec le Java JDK 1.7 dépendant, puis configure, démarre et installe Tomcat. Comme vous pouvez le voir dans cet exemple, les fichiers pilotés par Ansible peuvent contenir des modèles Jinja, ce qui simplifie le calcul des valeurs et rend votre configuration plus flexible. Le code YAML est facile à lire et à écrire pour les administrateurs système et les développeurs. Cela conduit au fait qu'Ansible devient un système de gestion de configuration abordable pour les utilisateurs avancés et novices.

Exemple de code CM Puppet


Le Puppet de langage orienté sujet est basé sur Ruby, mais sa syntaxe est beaucoup plus proche des langages impératifs de style C comme Perl, Java et C ++. Cette approche est un intermédiaire entre les développeurs familiers avec Ruby et ceux qui ne connaissent peut-être pas ce langage. Par conséquent, vous n'aurez peut-être pas besoin de connaître Ruby pour apprendre et utiliser Puppet DSL de manière productive.
Voici un exemple de manifeste Puppet du référentiel PuppetLabs MySQL Puppet Module qui installe et configure le package client MySQL:

# @summary
#     Installs and configures the MySQL client.
#
# @example Install the MySQL client
#     class {'::mysql::client':
#         package_name => 'mysql-client',
#         package_ensure => 'present',
#         bindings_enable => true,
#     }
#
# @param bindings_enable
#     Whether to automatically install all bindings. Valid values are `true`, `false`. Default to `false`.
# @param install_options
#     Array of install options for managed package resources. You must pass the appropriate options for the package manager.
# @param package_ensure
#     Whether the MySQL package should be present, absent, or a specific version. Valid values are 'present', 'absent', or 'x.y.z'.
# @param package_manage
#     Whether to manage the MySQL client package. Defaults to `true`.
# @param package_name
#     The name of the MySQL client package to install.
#
class mysql::client (
    $bindings_enable = $mysql::params::bindings_enable,
    $install_options = undef,
    $package_ensure = $mysql::params::client_package_ensure,
    $package_manage = $mysql::params::client_package_manage,
    $package_name = $mysql::params::client_package_name,
)  inherits mysql::params {
    
    include '::mysql::client::install'

    if $bindings_enable {
        class { 'mysql::bindings':
            java_enable => true,
            perl_enable => true,
            php_enable => true,
            python_enable => true,
            ruby_enable => true,
        }
    }

# Anchor pattern workaround to avoid resources of mysql::client::install to
# "float off" outside mysql::client
anchor { 'mysql::client::start': }
-> Class['mysql::client::install']
-> anchor { 'mysql::client::end': }
}

Un avantage important de Puppet est que, contrairement aux langages de programmation impératifs répertoriés ci-dessus, Puppet DSL est déclaratif, à certains égards similaire à XML, ainsi que le code YAML de l'exemple de code Ansible ci-dessus. L'approche déclarative de Puppet et d'Ansible est vraiment tracée dans les deux exemples de code. En termes de codage, ils sont similaires et plus proches les uns des autres que des outils comme Chef. Cependant, le langage déclaratif Puppet fournit également des constructions de type Ruby telles que des expressions conditionnelles et des itérations, ce qui constitue à nouveau un compromis pour les utilisateurs de Ruby et ceux qui ne parlent pas le langage.

Ansible vs Puppet: Facilité d'utilisation


Pour l'équipe de développement, la facilité d'utilisation devrait être un élément important de l'évaluation de SCM. Étant donné que les développeurs d'Ansible se concentrent beaucoup sur la facilité d'utilisation du système, il n'y a pas de concurrents dans ce domaine. La configuration, la programmation et la gestion des nœuds fournissent une interface très simple aux ingénieurs de développement et aux administrateurs système.

Cela ne signifie pas que Puppet est difficile à utiliser, c'est juste que ce système se comporte en toute confiance pendant que vous suivez la méthode proposée d'automatisation de son infrastructure. Dans ce domaine, Puppet est assez puissant, modélisant explicitement chaque ressource et fournissant aux utilisateurs des modules avec un comportement standard qui sont efficacement utilisés dans vos manifestes.

En termes d'apprentissage utilisateur, les deux plates-formes sont faciles à utiliser, mais Ansible a un léger avantage. Il est facile d'obtenir un style YAML déclaratif, donc le code Ansible n'est jamais trop compliqué. Pendant ce temps, Puppet a fini par reconnaître certains des problèmes associés à la combinaison de données et de code dans les mêmes fichiers source. Cela a conduit à l'avènement de Puppet Hiera, une solution de stockage qui utilise le format YAML pour stocker des paires clé-valeur de données de configuration. Hiera va un long chemin vers la simplification et l'optimisation de l'expérience Puppet DevOps. Le format YAML s'est avéré très populaire pour la gestion de la configuration, Salt de SaltStack utilisant également ce format.
Les deux SCM ont la capacité de valider et de tester votre CM, de la vérification de la syntaxe à l'intégration de l'infrastructure en tant que code.

Ansible vs Puppet: coûts de licence et d'implémentation





En tant qu'outils open source, Ansible et Puppet ont beaucoup en commun dans leurs politiques de licence.

La version open source d'Ansible est entièrement gratuite. Les entreprises qui ont besoin de plus de garanties de sécurité, de stabilité et de fiabilité sont encouragées à passer à Ansible Engine, le produit de classe entreprise fourni avec Red Hat Linux. Les coûts de licence Ansible Engine varient généralement de 47,50 $ à 70 $ par an et par nœud et dépendent de votre configuration préférée.

Si vous avez besoin d'une assistance technique avec un dépannage rapide, vous devez utiliser la version entreprise. L'outil de gestion pour grandes entreprises Ansible Tower est disponible sous forme de package de services et offre à votre entreprise davantage de capacités de formation, de gestion et de planification des tâches via un panneau de commande graphique.

Comme Ansible, la version open source Puppet est disponible gratuitement. Pour des fonctionnalités d'entreprise et un support technique supplémentaires, les organisations peuvent passer à Puppet Enterprise, qui coûte de 112 $ à 199 $ par an et par nœud. Puppet Enterprise propose un ensemble de plusieurs outils, notamment la génération de rapports et la surveillance de l'état de l'infrastructure d'entreprise.

Ansible vs Puppet: Communauté


Puppet, sorti en 2005, est un ancien outil DevOps, il a donc eu plus de temps pour créer sa propre communauté et sa propre base d'utilisateurs. Néanmoins, Ansible, lancé en 2012, grâce à sa nouvelle approche, a réussi à attirer un public encore plus large et à créer une communauté très dynamique de développeurs passionnés et d'utilisateurs. Les utilisateurs de marionnettes incluent des sociétés telles que Uber, Salesforce et Paypal, tandis que la communauté Ansible comprend des sociétés telles que Digital Ocean, 9GAG et TypeForm.

Si nous comparons un indicateur aussi important du développement de produits open source que le nombre de contributeurs participant au développement sur GitHub, Ansible avec plus de 4800 contributeurs est de loin supérieur à Puppet avec ses 527 contributeurs au développement de produits. Le développement d'Ansible au cours des dernières années a été si rapide qu'il a donné lieu à la création d'un référentiel "galactique" séparé d' Ansible Galaxy . Cela signifie que la communauté Ansible s'efforce de partager son code, contribuant ainsi au développement ultérieur du produit.

Pendant ce temps, la communauté Puppet, qui se développe plus lentement et régulièrement, a créé une infrastructure pour faciliter la recherche de solutions répondant à vos besoins SCM. Puppet Forge fournit des modules pour les tâches de gestion de configuration courantes pour la communauté Puppet.

Les deux systèmes disposent d'outils de premier ordre pour surveiller le cycle de vie d'un projet de gestion de configuration via la ligne de commande. Puppet et Ansible s'intègrent bien avec d'autres systèmes DevOps largement utilisés tels que Docker, Kubernetes et Jenkins, et les plateformes de cloud computing AWS et Azure.

Ansible vs Puppet: quel est le meilleur?


Dans ce domaine, le choix vous appartient. Le style déclaratif d'Ansible et de Puppet signifie que ces outils ont beaucoup plus en commun que les autres systèmes de gestion de configuration. Cependant, pour faire le meilleur choix, vous devez accorder une attention particulière à la façon dont les besoins de votre équipe sont combinés avec la conception et les avantages d'un SCM particulier.
Ansible est mieux adapté pour ceux qui sont intéressés par une configuration de type YAML et partagent la philosophie Ansible d'être aussi simple que possible tout en gérant rapidement et simultanément un large pool de machines. De plus, cette philosophie se concentre sur l'utilisation des fonctions SSH existantes au lieu de créer des agents utilisateurs.

Puppet convient mieux aux équipes qui préfèrent DSL, qui modélise les ressources système de manière cohérente et répétitive. C'est exactement ce que fait Puppet DSL, avec tout un écosystème d'outils pour rendre les grandes équipes prévisibles et faciles.

Si vous savez exactement quels principes de gestion de configuration répondent le mieux à vos besoins, choisir entre Puppet et Ansible ne vous posera pas de problème.

résultats


Pour faciliter votre choix, nous vous suggérons de vous familiariser avec les principaux avantages et inconvénients des deux systèmes.



Un peu de publicité :)


Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis des VPS basés sur le cloud pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur les VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?

All Articles