PuppetConf 2016. Kubernetes для сисадминов. Часть 1
PuppetConf 2016. Kubernetes для сисадминов. Часть 2
Мы берем приложение Lobsters и создаем новый образ с новыми требованиями. Сначала вводим команду развертывания $ kubectl apply –f deployments/lobsters.yaml и посылаем приложение в кластер, который должен выполнить обновление rolling update для каждого из имеющихся экземпляров приложения в соответствии с политикой обновлений. Сначала система убеждается в работоспособности каждого экземпляра, а затем уничтожает их в следующем наборе контейнеров.
![](https://habrastorage.org/webt/xg/bl/xe/xgblxesodan5f7msgrj_d3qc0x4.jpeg)
Посмотрим, как это сработало. Для этого перезагружаем сайт, и теперь отсутствие белых мест сделает нашего маркетолога счастливым.
![](https://habrastorage.org/webt/0y/tu/r3/0ytur3i7hpga4pd8blgqpltetpk.jpeg)
Как сисадмин, вы можете сказать: «Здесь же нет HTTPS, такие сайты легко взломать, это же опасно!». Как же можно решить эту проблему? Я думаю, в ее решении Kubernetes может выступать как фреймворк, который позволяет системному администратору реализовать творческий подход к работе. Было бы хорошо, если я мог бы декларативно сказать: «Я хочу получить для этого сайта сертификат Let's Encrypt, но при этом не хочу повторно развертывать данный контейнер». Я хочу сделать это в рамках своих возможностей, не обращаясь за помощью к команде разработчиков приложения. Kubernetes позволяет подобное, так как поддерживает пользовательские расширения.
Я говорил про kubectl, поды, развертывания, services, но у нас есть еще и custom types — пользовательские типы ресурсов, которые можно получить в Puppet. В Puppet мы можем дать определение новым типам, так что мы можем использовать эту систему для нашей работы.
Посмотрим, как это выглядит в Kubernetes. В первую очередь нам нужно расширение для сертификатов, вот как оно выглядит. Здесь у нас имеется свое собственное пространство имен hightower.com, в котором расположен сертифицируемый объект.
![](https://habrastorage.org/webt/rr/ma/5r/rrma5rckamyozcp6nnmpbtgyl7c.jpeg)
Мы создаем в Kubernetes новое расширение с помощью команды $ kubectl create –f extensions/certificate.yaml, при этом в бэкенде автоматически создается хранилище и осуществляется управление данным состоянием.
![](https://habrastorage.org/webt/f6/ea/d2/f6ead2a5oznwql3lmm4x1vfdroq.jpeg)
Появление этого нового объекта требует от меня нового инструмента, отслеживающего изменения и совершающего действия в отношении объекта certificate. То есть этот инструмент в фоновом режиме должен взаимодействовать с Let's Encrypt и получить действующий сертификат. Для этого я использую secret – покажу очень быстро, как это делается.
Итак, нам нужен новый под, и я покажу, в чем разница по сравнению с предыдущим кодом. Я добавляю в существующий под контейнер nginx, так что нам не нужно обращаться к команде разработчиков. Мы продолжаем использовать HTTPS, просто разместив контейнер в самом верху существующего пода.
![](https://habrastorage.org/webt/g7/03/86/g70386ln3tvhoqjmebrbvryzpzq.jpeg)
Этот контейнер принимает HTTPS-трафик, и ему нужен файл конфигурации для взаимодействия с бэкендом. Мне также нужны некоторые сертификаты, которые nginx загружает из файловой системы, поэтому переменные окружения здесь не работают. Я не писал nginx, так что не могу заставить его это делать.
![](https://habrastorage.org/webt/_a/cl/2i/_acl2isasvxctjkvufkrugqnk8k.jpeg)
Поэтому я просто добавляю этот контейнер прямо внутрь пода и обращаюсь к двум secrets.
![](https://habrastorage.org/webt/yc/iv/eq/yciveqwa-pq7_cck1gf60hfjqn8.jpeg)
Первый и самый главный secret – это TLS-сертификат, который должен поступить с Let's Encrypt. Я не собираюсь сообщать о Let's Encrypt своему приложению, я сообщаю о нем своей системе. Я хочу распоряжаться этой абстракцией. Поэтому сейчас я должен создать config-файл для nginx. Это основной файл конфигурации, который выглядит таким образом.
Здесь указан порт 443 и включен SSL, который ищет в файловой системе эти 2 файла, захватывает трафик и отправляет его локальному хосту 127.0.0.1:3000.
![](https://habrastorage.org/webt/-2/kd/5y/-2kd5yagcajoerql82qqk13j7x8.jpeg)
Это именно то, что «слушает» мое приложение. Сейчас я создам configmap — карту конфигурации nginx, используя следующую команду.
![](https://habrastorage.org/webt/9c/o7/cw/9co7cwksmacc2wupjily8lafopw.jpeg)
Теперь с помощью команды $ kubectl get configmaps я размещаю configmap «nginx» в системе с таким же именем, что и у диска.
![](https://habrastorage.org/webt/xd/ra/gj/xdragjavd0y5qozvclnjhgarhoo.jpeg)
Далее необходимо создать secret, напомню вам еще раз – я хочу, чтобы все было автоматизированным, и не хочу вмешиваться в процесс получения сертификатов. Для этого я развертываю инструмент под названием «kube-cert-manager», и вот что получается в результате.
![](https://habrastorage.org/webt/2q/al/nf/2qalnfsodexfhlnz6wrmdczbhuk.jpeg)
Мы пытаемся получить действительный сертификат Let’s Encrypt, которому будет доверять мой браузер, и вставляем его в бэкенд как secret. Поэтому для моего пода не будет никакой разницы в том, что мы дополнили его содержимое. Если помните, все это сделано благодаря созданию custom type в Puppet.
Возможно, это плохая идея, но сейчас я постараюсь запустить контроллер, который будет работать в бэкграунде. Мы не делаем никакой компиляции, не создаем провайдеров, этот деймон просто работает в фоне и наблюдает за изменениями. Как только появляется объект сертификата, он получает его с Let’s Encrypt и вставляет в систему в режиме реального времени без всяких задержек. Итак, я использую следующую команду.
![](https://habrastorage.org/webt/a4/99/zo/a499zou6q5d0mmb-dudvreekhyg.jpeg)
У этой штуки тоже есть хранилище, так что мы можем сохранить все что нужно. Требуется несколько секунд, чтобы менеджер сертификации kube-cert-manager начал работать.
![](https://habrastorage.org/webt/p4/6i/gc/p46igctf-yljcjod5tgweyo9pnq.jpeg)
Следующее, что нам нужно сделать, — это создать объект сертификата. Это то, что я определяю сам, это моя собственная схема. Я создаю новую вещь, которую Kubernetes не встречал до этого момента, в которой говорится, что я могу получить сертификат для домена lobsters.com.
![](https://habrastorage.org/webt/hq/yl/kd/hqylkdbzfn7vdps0b5drmv8jbpm.jpeg)
Здесь имеется адрес электронной почты и другая информация, которая необходима для того, чтобы Let’s Encrypt выдал мне действительный сертификат. Let’s Encrypt пришлет мне обменный токен, чтобы увидеть, действительно ли я являюсь владельцем этого домена, и мне нужно будет применить этот токен к моему DNS в Google Cloud. Если проверка пройдет, то они выдадут мне настоящий сертификат, который я вставлю в свою файловую систему. Посмотрим, как это работает, введя команду $ kubectl get pods.
![](https://habrastorage.org/webt/pb/6u/za/pb6uzapiyin51rbygpmlorvu3pw.jpeg)
Как видите, менеджер сертификатов все еще работает. Посмотрим подробную информацию об этом процессе с помощью команды $ kubectl describe pods kube-cert-manager, вставив название контейнера из первой строки кода.
![](https://habrastorage.org/webt/wg/ly/xe/wglyxeqwjbcurcrse2hshtjw_ji.jpeg)
Вы видите, что выполняется работа по расписанию. В данный момент на сервере создается том, который после проверки и форматирования будет смонтирован на этом сервере. Пока идет этот процесс, можно пойти дальше и закончить нашу работу.
Я ввожу команду kubectl create –f certificates/lobsters.yaml и получаю следующий результат.
![](https://habrastorage.org/webt/z5/hp/gp/z5hpgphmdzfu4rtwj1dq0bntpwg.jpeg)
Далее я использую команду, которая позволяет просмотреть логи нескольких контейнеров. Я выделю тот, что касается моего объекта.
![](https://habrastorage.org/webt/sz/wx/ef/szwxef5zwbj9zy-r4simoyc8nji.jpeg)
Сейчас происходит создание записи DNS внутри моего облачного DNS-сервера. Если я обновлю изображенную здесь страницу, то увижу новый обменный токен с расширением .txt.
![](https://habrastorage.org/webt/n_/z4/rf/n_z4rfe1bpsde1qtie1km2dwxhs.jpeg)
Итак, я получил токен от Let’s Encrypt и теперь проверяю, что эта запись DNS распространилась по всем авторизированным серверам, прежде чем я скажу Let’s Encrypt, чтобы они проверили эту текстовую запись в моем домене.
![](https://habrastorage.org/webt/mb/ma/pr/mbmaprqr4ddkxyuytws68cgj-u8.jpeg)
Если это сработает, они пришлют мне обратно действующий сертификат. Демонстрация работы DNS в режиме реального времени – плохая идея. Ага, мы наконец получаем сертификат. Let’s Encrypt заметил, что сертификат исчез из Kubernetes, и вставил его туда. Это отлично, потому сейчас у меня уже имеется интерфейс запроса сертификатов для всего, что выполняется в среде Kubernetes.
Чтобы убедится, что все работает правильно, я ввожу команду $ kubectl get secrets, и мы видим один secret для сайта lobsters.hightowerlabs.com.
![](https://habrastorage.org/webt/b7/ff/j1/b7ffj1jembzr8j1htlpxkrxkcoa.jpeg)
Теперь я использую команду $ kubectl delete secrets lobsters.hightowerlabs.com, потому что это декларативная система, мы не удаляем объект сертификата, а избавляемся от связанного с ним secret, расположенного внутри Kubernetes. В результате мы должны убедиться в том, что при удалении этого элемента система вернет на место сам сертификат Let’s Encrypt. Это очень похоже на то, что мы делаем в Puppet, только здесь это происходит в режиме онлайн.
Убедившись, что все работает, мы осуществляем новое развертывание нашего приложения nginx под названием «lobsters-secure», которое обеспечит безопасность нового домена. Его образ похож на предыдущий вариант, но разница состоит в том, что мы поместили сюда nginx. Nginx забирает по ссылке secrets, затем Kubernetes вставляет его в файловую систему, в результате чего я получаю действующий сертификат для конкретного домена.
Для этого я ввожу команду $ kubectl apply –f deployments/lobsters-secure.yaml, используя то же самое имя, так что эта команда перепишет существующее состояние. Далее используется команда $ kubectl get pods, которая показывает, что сейчас здесь происходит скользящее обновление rolling update, поскольку у нас поменялись определения definition.
После завершения обновления видно, что для данного приложения используются новые definition. Я хочу убедиться в действительности сертификата для нашего DNS-имени, для чего ввожу команду $ kubectl get svc и копирую IP-адрес сайта lobsters.
![](https://habrastorage.org/webt/bf/tv/i4/bftvi4mtuaqz29b5eelp25eqets.jpeg)
Перейдя на вкладку Google Cloud, видно, что этот адрес совпадает с адресом, соответствующим доменному имени lobsters.hightowerlabs.com. Теперь, если набрать в адресной строке браузера lobsters.hightowerlabs.com, можно увидеть, что у нас имеется действующий сертификат.
![](https://habrastorage.org/webt/zx/se/z5/zxsez5z5vhqg3e3cxkuqzs7jc84.jpeg)
Благодарю вас, это все, что я хотел рассказать в докладе «Kubernetes для системных администраторов».
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
PuppetConf 2016. Kubernetes для сисадминов. Часть 2
Мы берем приложение Lobsters и создаем новый образ с новыми требованиями. Сначала вводим команду развертывания $ kubectl apply –f deployments/lobsters.yaml и посылаем приложение в кластер, который должен выполнить обновление rolling update для каждого из имеющихся экземпляров приложения в соответствии с политикой обновлений. Сначала система убеждается в работоспособности каждого экземпляра, а затем уничтожает их в следующем наборе контейнеров.
![](https://habrastorage.org/webt/xg/bl/xe/xgblxesodan5f7msgrj_d3qc0x4.jpeg)
Посмотрим, как это сработало. Для этого перезагружаем сайт, и теперь отсутствие белых мест сделает нашего маркетолога счастливым.
![](https://habrastorage.org/webt/0y/tu/r3/0ytur3i7hpga4pd8blgqpltetpk.jpeg)
Как сисадмин, вы можете сказать: «Здесь же нет HTTPS, такие сайты легко взломать, это же опасно!». Как же можно решить эту проблему? Я думаю, в ее решении Kubernetes может выступать как фреймворк, который позволяет системному администратору реализовать творческий подход к работе. Было бы хорошо, если я мог бы декларативно сказать: «Я хочу получить для этого сайта сертификат Let's Encrypt, но при этом не хочу повторно развертывать данный контейнер». Я хочу сделать это в рамках своих возможностей, не обращаясь за помощью к команде разработчиков приложения. Kubernetes позволяет подобное, так как поддерживает пользовательские расширения.
Я говорил про kubectl, поды, развертывания, services, но у нас есть еще и custom types — пользовательские типы ресурсов, которые можно получить в Puppet. В Puppet мы можем дать определение новым типам, так что мы можем использовать эту систему для нашей работы.
Посмотрим, как это выглядит в Kubernetes. В первую очередь нам нужно расширение для сертификатов, вот как оно выглядит. Здесь у нас имеется свое собственное пространство имен hightower.com, в котором расположен сертифицируемый объект.
![](https://habrastorage.org/webt/rr/ma/5r/rrma5rckamyozcp6nnmpbtgyl7c.jpeg)
Мы создаем в Kubernetes новое расширение с помощью команды $ kubectl create –f extensions/certificate.yaml, при этом в бэкенде автоматически создается хранилище и осуществляется управление данным состоянием.
![](https://habrastorage.org/webt/f6/ea/d2/f6ead2a5oznwql3lmm4x1vfdroq.jpeg)
Появление этого нового объекта требует от меня нового инструмента, отслеживающего изменения и совершающего действия в отношении объекта certificate. То есть этот инструмент в фоновом режиме должен взаимодействовать с Let's Encrypt и получить действующий сертификат. Для этого я использую secret – покажу очень быстро, как это делается.
Итак, нам нужен новый под, и я покажу, в чем разница по сравнению с предыдущим кодом. Я добавляю в существующий под контейнер nginx, так что нам не нужно обращаться к команде разработчиков. Мы продолжаем использовать HTTPS, просто разместив контейнер в самом верху существующего пода.
![](https://habrastorage.org/webt/g7/03/86/g70386ln3tvhoqjmebrbvryzpzq.jpeg)
Этот контейнер принимает HTTPS-трафик, и ему нужен файл конфигурации для взаимодействия с бэкендом. Мне также нужны некоторые сертификаты, которые nginx загружает из файловой системы, поэтому переменные окружения здесь не работают. Я не писал nginx, так что не могу заставить его это делать.
![](https://habrastorage.org/webt/_a/cl/2i/_acl2isasvxctjkvufkrugqnk8k.jpeg)
Поэтому я просто добавляю этот контейнер прямо внутрь пода и обращаюсь к двум secrets.
![](https://habrastorage.org/webt/yc/iv/eq/yciveqwa-pq7_cck1gf60hfjqn8.jpeg)
Первый и самый главный secret – это TLS-сертификат, который должен поступить с Let's Encrypt. Я не собираюсь сообщать о Let's Encrypt своему приложению, я сообщаю о нем своей системе. Я хочу распоряжаться этой абстракцией. Поэтому сейчас я должен создать config-файл для nginx. Это основной файл конфигурации, который выглядит таким образом.
Здесь указан порт 443 и включен SSL, который ищет в файловой системе эти 2 файла, захватывает трафик и отправляет его локальному хосту 127.0.0.1:3000.
![](https://habrastorage.org/webt/-2/kd/5y/-2kd5yagcajoerql82qqk13j7x8.jpeg)
Это именно то, что «слушает» мое приложение. Сейчас я создам configmap — карту конфигурации nginx, используя следующую команду.
![](https://habrastorage.org/webt/9c/o7/cw/9co7cwksmacc2wupjily8lafopw.jpeg)
Теперь с помощью команды $ kubectl get configmaps я размещаю configmap «nginx» в системе с таким же именем, что и у диска.
![](https://habrastorage.org/webt/xd/ra/gj/xdragjavd0y5qozvclnjhgarhoo.jpeg)
Далее необходимо создать secret, напомню вам еще раз – я хочу, чтобы все было автоматизированным, и не хочу вмешиваться в процесс получения сертификатов. Для этого я развертываю инструмент под названием «kube-cert-manager», и вот что получается в результате.
![](https://habrastorage.org/webt/2q/al/nf/2qalnfsodexfhlnz6wrmdczbhuk.jpeg)
Мы пытаемся получить действительный сертификат Let’s Encrypt, которому будет доверять мой браузер, и вставляем его в бэкенд как secret. Поэтому для моего пода не будет никакой разницы в том, что мы дополнили его содержимое. Если помните, все это сделано благодаря созданию custom type в Puppet.
Возможно, это плохая идея, но сейчас я постараюсь запустить контроллер, который будет работать в бэкграунде. Мы не делаем никакой компиляции, не создаем провайдеров, этот деймон просто работает в фоне и наблюдает за изменениями. Как только появляется объект сертификата, он получает его с Let’s Encrypt и вставляет в систему в режиме реального времени без всяких задержек. Итак, я использую следующую команду.
![](https://habrastorage.org/webt/a4/99/zo/a499zou6q5d0mmb-dudvreekhyg.jpeg)
У этой штуки тоже есть хранилище, так что мы можем сохранить все что нужно. Требуется несколько секунд, чтобы менеджер сертификации kube-cert-manager начал работать.
![](https://habrastorage.org/webt/p4/6i/gc/p46igctf-yljcjod5tgweyo9pnq.jpeg)
Следующее, что нам нужно сделать, — это создать объект сертификата. Это то, что я определяю сам, это моя собственная схема. Я создаю новую вещь, которую Kubernetes не встречал до этого момента, в которой говорится, что я могу получить сертификат для домена lobsters.com.
![](https://habrastorage.org/webt/hq/yl/kd/hqylkdbzfn7vdps0b5drmv8jbpm.jpeg)
Здесь имеется адрес электронной почты и другая информация, которая необходима для того, чтобы Let’s Encrypt выдал мне действительный сертификат. Let’s Encrypt пришлет мне обменный токен, чтобы увидеть, действительно ли я являюсь владельцем этого домена, и мне нужно будет применить этот токен к моему DNS в Google Cloud. Если проверка пройдет, то они выдадут мне настоящий сертификат, который я вставлю в свою файловую систему. Посмотрим, как это работает, введя команду $ kubectl get pods.
![](https://habrastorage.org/webt/pb/6u/za/pb6uzapiyin51rbygpmlorvu3pw.jpeg)
Как видите, менеджер сертификатов все еще работает. Посмотрим подробную информацию об этом процессе с помощью команды $ kubectl describe pods kube-cert-manager, вставив название контейнера из первой строки кода.
![](https://habrastorage.org/webt/wg/ly/xe/wglyxeqwjbcurcrse2hshtjw_ji.jpeg)
Вы видите, что выполняется работа по расписанию. В данный момент на сервере создается том, который после проверки и форматирования будет смонтирован на этом сервере. Пока идет этот процесс, можно пойти дальше и закончить нашу работу.
Я ввожу команду kubectl create –f certificates/lobsters.yaml и получаю следующий результат.
![](https://habrastorage.org/webt/z5/hp/gp/z5hpgphmdzfu4rtwj1dq0bntpwg.jpeg)
Далее я использую команду, которая позволяет просмотреть логи нескольких контейнеров. Я выделю тот, что касается моего объекта.
![](https://habrastorage.org/webt/sz/wx/ef/szwxef5zwbj9zy-r4simoyc8nji.jpeg)
Сейчас происходит создание записи DNS внутри моего облачного DNS-сервера. Если я обновлю изображенную здесь страницу, то увижу новый обменный токен с расширением .txt.
![](https://habrastorage.org/webt/n_/z4/rf/n_z4rfe1bpsde1qtie1km2dwxhs.jpeg)
Итак, я получил токен от Let’s Encrypt и теперь проверяю, что эта запись DNS распространилась по всем авторизированным серверам, прежде чем я скажу Let’s Encrypt, чтобы они проверили эту текстовую запись в моем домене.
![](https://habrastorage.org/webt/mb/ma/pr/mbmaprqr4ddkxyuytws68cgj-u8.jpeg)
Если это сработает, они пришлют мне обратно действующий сертификат. Демонстрация работы DNS в режиме реального времени – плохая идея. Ага, мы наконец получаем сертификат. Let’s Encrypt заметил, что сертификат исчез из Kubernetes, и вставил его туда. Это отлично, потому сейчас у меня уже имеется интерфейс запроса сертификатов для всего, что выполняется в среде Kubernetes.
Чтобы убедится, что все работает правильно, я ввожу команду $ kubectl get secrets, и мы видим один secret для сайта lobsters.hightowerlabs.com.
![](https://habrastorage.org/webt/b7/ff/j1/b7ffj1jembzr8j1htlpxkrxkcoa.jpeg)
Теперь я использую команду $ kubectl delete secrets lobsters.hightowerlabs.com, потому что это декларативная система, мы не удаляем объект сертификата, а избавляемся от связанного с ним secret, расположенного внутри Kubernetes. В результате мы должны убедиться в том, что при удалении этого элемента система вернет на место сам сертификат Let’s Encrypt. Это очень похоже на то, что мы делаем в Puppet, только здесь это происходит в режиме онлайн.
Убедившись, что все работает, мы осуществляем новое развертывание нашего приложения nginx под названием «lobsters-secure», которое обеспечит безопасность нового домена. Его образ похож на предыдущий вариант, но разница состоит в том, что мы поместили сюда nginx. Nginx забирает по ссылке secrets, затем Kubernetes вставляет его в файловую систему, в результате чего я получаю действующий сертификат для конкретного домена.
Для этого я ввожу команду $ kubectl apply –f deployments/lobsters-secure.yaml, используя то же самое имя, так что эта команда перепишет существующее состояние. Далее используется команда $ kubectl get pods, которая показывает, что сейчас здесь происходит скользящее обновление rolling update, поскольку у нас поменялись определения definition.
После завершения обновления видно, что для данного приложения используются новые definition. Я хочу убедиться в действительности сертификата для нашего DNS-имени, для чего ввожу команду $ kubectl get svc и копирую IP-адрес сайта lobsters.
![](https://habrastorage.org/webt/bf/tv/i4/bftvi4mtuaqz29b5eelp25eqets.jpeg)
Перейдя на вкладку Google Cloud, видно, что этот адрес совпадает с адресом, соответствующим доменному имени lobsters.hightowerlabs.com. Теперь, если набрать в адресной строке браузера lobsters.hightowerlabs.com, можно увидеть, что у нас имеется действующий сертификат.
![](https://habrastorage.org/webt/zx/se/z5/zxsez5z5vhqg3e3cxkuqzs7jc84.jpeg)
Благодарю вас, это все, что я хотел рассказать в докладе «Kubernetes для системных администраторов».
Немного рекламы :)
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?