Как установить бесплатный ssl-сертификат для сайта в ispmanager

Введение

Традиционно, буду использовать самые простые подручные средства, завернутые в консольные скрипты, которые будут передавать значения в zabbix с помощью UserParameter. Для уменьшения ручной работы, добавление доменов в систему мониторинга будет осуществляться с помощью автообнаружения. Сами списки доменов с сертификатами ssl для проверки будут храниться в текстовых файлах.

У нас будут 2 отдельных списка для проверки:

  1. Домены с ssl сертификатами для веб сайтов.
  2. Домены с ssl сертификатами для почтовых серверов.

Поясню, почему 2 списка. Ведь по сути, сертификаты в обоих случаях будут совершенно одинаковые. Дело в том, что у меня есть почтовые сервера, которые используют сертификаты, но при этом не имеют сайтов с таким же доменным именем. Для таких серверов заказаны отдельные сертификаты, которые установлены только на почтовом сервере и проверить их можно только по протоколам, которые используют почтовые серверы. Ниже я подробно раскрою все различия и способы проверки.

Если у вас еще нет готового сервера для мониторинга, предлагаю его настроить по моей статье — установка и настройка zabbix 3.4 на Centos 7. Если предпочитаете Debian, то вот материал на эту тему — установка и настройка zabbix 3.4 на Debian 9. В данном случае все можно сделать на одном сервере — достаточно на один сервер поставить zabbix-server и zabbix-agent.

Шаг 4 — Активация изменений в Apache

Мы внесли изменения и настроили брандмауэр, и теперь можем включить в Apache модули SSL и заголовков, активировать наш виртуальный хост SSL и перезапустить Apache.

Мы можем активровать , модуль Apache SSL, и модуль , необходимый для некоторых настроек нашего сниппета SSL, с помощью команды :

Теперь мы можем активировать виртуальный хост SSL с помощью команды :

Также нам нужно будет активировать файл для считывания заданных значений:

Если проверка будет успешно пройдена, мы получим результат, выглядящий примерно так:

Первая строка — это сообщение о том, что директива не задана глобально. Если вы хотите избавиться от этого сообщения, вы можете задать для доменное имя вашего сервера или IP-адрес в каталоге . Это необязательно, потому что данное сообщение не наносит никакого вреда.

Если в результатах есть сообщение , в вашей конфигурации нет синтаксических ошибок. Мы можем безопасно перезапустить Apache для внесения изменений:

Доверенные и недоверенные сертификаты

Выпуском SSL-сертификатов занимаются центры сертификации или, как их еще называют, удостоверяющие центы (Certification Authority, CA). Как правило, это авторитетные IT-организации, пользующиеся известным открытым криптографическим ключом:

  • Sectigo/Comodo;
  • GeoTrust;
  • RapidSSL;
  • Thawte и другие.

Сертификаты этих организаций называют доверенными. К недоверенным же сертификатам относятся:

  • самоподписанные сертификаты, которые владельцы сайтов выдают и подписывают сами себе;
  • сертификаты, подписанные недоверенными центрами;
  • цифровые подписи, выданные центрами, утратившими доверие.

Зачем сайту нужен сертификат SSL

Фактически главной функцией SSL-сертификата является генерация цифровой подписи web-сайта. Данная сигнатура определяет безопасность шифрования при соединении пользователей с интернет-площадкой.

Если такой сертификат отсутствует, то информация, которую вводят посетители в анкете или регистрационной форме могут похищаться мошенниками. Обычно их интересуют пароли банковских карточек, коды, электронные адреса.

Учитывая то, что сертификат SSL непосредственно обеспечивает безопасность, сразу параллельно стоит сделать перевод сайта на HTTPS. Это модель безопасной передачи информационных потоков, поэтому стоит сразу перейти на HTTPS-протокол.

Бесплатные сертификаты

Самоподписанные сертификаты

Самоподписанный (самоизданный, самозаверенный, self-signed) сертификат — тот, который вы сами создали для своего домена или IP-адреса. Многим владельцам сайтов может показаться, что это идеальный вариант:

  • Бесплатно.
  • Доступно. Такой SSL-сертификат может создать любой владелец домена.
  • Без обращения к поставщикам услуг. Не нужно ждать ответа от центра сертификации.
  • Быстро. Но только если вы знаете, что делать и как пользоваться специальными программами или библиотеками. Например, для Windows можно воспользоваться криптографическим хранилищем OpenSSL или консолью PowerShell. 
  • Можно создать сколько угодно сертификатов.

Вам уже кажется, что выбор сделан и читать дальше нет смысла? Всё не совсем так.

Минусы

  • Нет надёжной защиты. Браузеры не доверяют таким сертификатам, потому что заверяют их не специальные центры, а неизвестный им человек или юрлицо. 
  • Есть риск потерять данные. Причём как пользователей, так и ваши, с сайта компании.
  • Отпугивает посетителей сайта. Пользователи, заходя на страницу с самоподписанным сертификатом, видят предупреждение о небезопасности: в результате количество посетителей сайта, готовых совершать на нем действия, снижается. Мало ли что — вдруг сайт мошеннический.
  • Возможные ошибки в оформлении и отображении сертификата, если он был создан неправильно.

Если вам нужно провести тесты на внутренних ресурсах компании, а заморачиваться с доверенными сертификатами не хочется, можно сделать самоизданный SSL-сертификат. Но и здесь вы рискуете: если у вас крупная компания, понадобится много труда и времени, чтобы наладить работу и объяснить всем сотрудникам, что делать с этим страшным предупреждением об опасности. В целом же, на практике использовать такой сертификат точно не стоит.

Бесплатные доверенные сертификаты

Такие SSL-сертификаты можно оформить довольно быстро. Часто ими пользуются стартапы, чтобы понять, что вообще такое SSL и как это работает. Бывают только одного вида — DV SSL (Domain Validation). Это сертификаты, удостоверяющие доменное имя. 

Плюсы

  • Быстро. Такой сертификат могут выдать вам уже через несколько минут. Всё потому, что тип такого сертификата — DV (Domain Validation) SSL и для его оформления нужно только подтверждение владения доменом, как и у платных DV.
  • Просто получать и устанавливать.
  • Отлично подойдёт для теста с возможностью сэкономить в первые несколько месяцев.
  • Известные компании-поставщики. Те же Let’s Encrypt на рынке с 2012 года и поддерживаются Google, Facebook и другими крупными корпорациями.

Минусы

  • Небольшой срок действия. Например, сертификаты Let`s Encrypt необходимо перевыпускать каждые 3 месяца.
  • Сложности с продлением. Хостеры автоматически продлевают некоторые бесплатные сертификаты. Но здесь бывают проблемы. Перед выпуском сертификационный центр обращается к сайту за специальным файлом. Иногда он в системе не обнаруживается: не было места на диске и файл не записался, во время проверки почему-то закрылся доступ к сайту и пр. Итог один — сертификат не обновляется, а вы даже не узнаете об этом, если не решите вдруг проверить срок действия вручную.
  • Отсутствие поддержки. Для корректной работы SSL-сертификата важна грамотная полноценная поддержка (по телефону, по email, в чатах). Она недоступна для бесплатных SSL. На официальных сайтах удостоверяющих центров, как правило, размещены ответы на часто задаваемые вопросы, которые в основном описывают общие случаи и могут быть бесполезны для решения конкретной проблемы. Также есть неофициальная информация на тематических форумах, но среди неё ещё надо найти нужную.
  • Есть вероятность не заметить, что сертификат не работает. Как мы писали выше, посмотреть сроки действия сертификата можно вручную. Есть и другой способ: проверять даты с помощью специального скрипта, который не так просто создать. Поддержки нет. Если не проверять сроки, можно пропустить время продления, и сертификаты будут аннулированы. В безопасности сайта появятся дыры, посетители, увидев уведомление о ненадёжности сайта, станут покидать сайт и трафик снизится.

В 2017 году кредитное бюро Equifax сообщило о масштабном взломе: хакеры украли данные 143 млн человек — почти половины населения США. Это произошло отчасти из-за истечения срока действия сертификата, который был неактивным в течение 19 месяцев.

Creating a Self-Signed SSL Certificate

25 Мая 2020
|

Терминал

Что такое самоподписанный сертификат SSL?

Самозаверяющий сертификат SSL — это сертификат, подписанный лицом, которое его создало, а не доверенным центром сертификации. Самозаверяющие сертификаты могут иметь тот же уровень шифрования, что и доверенный CA-подписанный SSL-сертификат.

Самозаверяющие сертификаты, признанные действительными в любом браузере. Если вы используете самозаверяющий сертификат, веб-браузер покажет посетителю предупреждение о том, что сертификат веб-сайта невозможно проверить.

Самозаверяющие сертификаты в основном используются для целей тестирования или внутреннего использования. Вы не должны использовать самозаверяющий сертификат в производственных системах, которые подключены к Интернету.

Предпосылки 

Инструментарий openssl необходим для создания самозаверяющего сертификата.

Чтобы проверить, установлен ли пакет openssl в вашей системе Linux, откройте ваш терминал, введите и нажмите Enter. Если пакет установлен, система распечатает версию OpenSSL, в противном случае вы увидите нечто подобное .

Если пакет openssl не установлен в вашей системе, вы можете установить его, выполнив следующую команду:

  • Ubuntu и Debian

  • Чентос и Федора

Создание самоподписанного SSL-сертификата 

Чтобы создать новый самоподписанный сертификат SSL, используйте команду:

Давайте разберем команду и разберемся, что означает каждая опция:

  • — Создает новый запрос сертификата и 4096-битный ключ RSA. Значение по умолчанию составляет 2048 бит.
  • — Создает сертификат X.509.
  • — Используйте 265-битный SHA (алгоритм безопасного хэширования).
  • — Количество дней для сертификации сертификата. 3650 — это 10 лет. Вы можете использовать любое положительное целое число.
  • — Создает ключ без ключевой фразы.
  • — Указывает имя файла, в который будет записан вновь созданный сертификат. Вы можете указать любое имя файла.
  • — Задает имя файла, в который будет записан вновь созданный закрытый ключ. Вы можете указать любое имя файла.

Для получения дополнительной информации о параметрах команды посетите страницу документации OpenSSL req.

Как только вы нажмете Enter, команда сгенерирует закрытый ключ и задаст вам ряд вопросов, которые она будет использовать для генерации сертификата.

Введите запрашиваемую информацию и нажмите Enter.

Сертификат и закрытый ключ будут созданы в указанном месте. Используйте команду ls, чтобы убедиться, что файлы были созданы:

Это оно! Вы создали новый самозаверяющий сертификат SSL.

Всегда полезно создать резервную копию нового сертификата и ключа для внешнего хранилища.

Создание самоподписанного SSL-сертификата без запроса

Если вы хотите сгенерировать самозаверяющий SSL-сертификат без запроса какого-либо вопроса, используйте параметр и укажите всю информацию о субъекте:

Поля, указанные в строке, перечислены ниже:

  • — Название страны. Двухбуквенное сокращение ISO.
  • — Название штата или провинции.
  • — Название населенного пункта. Название города, в котором вы находитесь.
  • — Полное название вашей организации.
  • — Организационная единица.
  • — Полное доменное имя.

В этом руководстве мы показали, как создать самозаверяющий сертификат SSL с помощью инструмента openssl. Теперь, когда у вас есть сертификат, вы можете настроить приложение для его использования.

Бесплатные сертификаты SSL/TLS от Let’s Encrypt

Рекомендую воспользоваться сертификатами SSL/TLS от Let’s Encrypt, так как:

  1. Они бесплатные;
  2. Подойдут большинству проектов;
  3. Установка и настройка относительно несложные, и не займут много сил и времени.

Из минусов — сертификат актуален 90 дней, поэтому настроим его обновление на автомате.

Установка Certbot

Сам гайд по установке Let’s Encrypt советует делать всё через Certbot. Сработает, если есть доступ по SSH.

Установка Certbot в Debian 8 Jessie

Помощник Certbot в выборе версии сервера

Выбираем установку

apt-get install certbot -t jessie-backports
Как настроить поддержку Backports

Пишете в консоль (добавляет дополнительный источник для пакетов):

echo "deb http://ftp.debian.org/debian jessie-backports main contrib non-free" >> /etc/apt/sources.list

Потом обновляете список пакетов:

apt-get update

и снова пробуете установить Certbot:

apt-get install certbot -t jessie-backports

Затем проверяете, как вышло

certbot --help

Установка Certbot в CentOS 7

Установка происходит так:

  1. yum -y install yum-utils
  2. yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional
  3. yum install certbot

Универсальная инструкция по установке Certbot

  1. Скачиваем Certbot:
    wget https://dl.eff.org/certbot-auto
  2. Даём права на исполнение с помощью chmod
    chmod a+x certbot-auto
  3. Перемещаем certbot-auto к остальным бинарным файлам, чтобы появилась возможность начинать команды с
    mv certbot-auto /usr/local/bin/certbot
  4. Проверяем, что получилось:
    certbot --help

    Должы увидеть что-то подобное:

Настройка Certbot

Теперь, когда certbot установлен (а вы можете убедиться в этом, задав команду), советую заглянуть в cron-задачи

cd /etc/cron.d

В директории должен появиться файл с примерно следующим содержанием

Самая последняя строчка — это правило cron, которое будет проверять сертификаты SSL, TLS дважды в день и обновлять устаревшие. К сожалению, он не перезагружает вебсервер, поэтому Вам нужно добавить правило вручную в конец строки.

В итоге, строка будет выглядеть примерно так:

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew && /etc/init.d/nginx reload

Добавили, сохраняем.

Далее, подготовка, тестирование и установка сертификата для сайта.

Подготовка и тестирование конфигурации SSL, TLS

Перед тем, как получить сертификат SSL/TLS, хорошей практикой будет протестировать правильность настройки сервера. Дело в том, что если есть проблема, которая не даст получить или обновить сертификат: центр сертификации имеет жёсткие лимиты обращений к нему (10 в час). И если есть ошибка, которую никак не удаётся выявить, то можно очень быстро упереться в лимит. Чтобы избежать этой проблемы, можно воспользоваться Staging Environment от Let’s Encrypt. — это тестовая среда, полностью имитирующая общение с центром сертификации, и выдающая недоверенные сертификаты-пустышки. Однако, она имеет повышенные лимиты обращения к ней и служит исключительно для тестирования и настройки конфигурации сервера:

  • Выдача и обновление сертификата на 1 домен имеет лимит 30 000 в неделю.
  • Ошибка валидации имеет лимит 60 раз в час.

Чтобы воспользоваться тестовой окружающей средой, достаточно для certbot использовать ключ .
Например, так можно протестировать выдачу сертификата:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email  --agree-tos --staging

Кстати, посмотреть, как происходит обновление сертификатов, но без реального обновления, просто проверить правильность конфигурации, можно командой:

certbot renew --dry-run

А обновить все сертификаты на сервере вручную можно командой

certbot renew

После перезагрузите NGINX

nginx -s reload

Установка сертификата SSL, TLS от Let’s Encrypt

Вводим команду в консоль Putty:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email  --agree-tos
  • — путь до директории с файлами сайта
  • — прописываем имена доменов
  • — ваш email, куда можно будет восстановить доступ
  • — согласие с лицензионными требованиями

Если всё нормально, вам выдаст сообщение об успешном завершении создания сертификата

Итак, сертификат установлен в директорию

Шаг 3 — Настройка брандмауэра

Если у вас включен брандмаэр в соответствии с предварительными требованиями, вам может потребоваться изменить настройки для поддержки трафика SSL . К счастью, Apache регистрирует несколько профилей после установки.

Мы можем просмотреть доступные профили с помощью следующей команды:

Список должен выглядеть примерно так:

Вы можете просмотреть текущие настройки с помощью следующей команды:

Если вам разрешен только обычный трафик HTTP, результаты могут выглядеть следующий образ:

Чтобы разрешить дополнительный трафик HTTPS, мы разрешим профиль «Apache Full» и удалим избыточный профиль «Apache»:

Теперь ваш статус должен выглядеть примерно так:

Что такое самоподписанный сертификат SSL?

Самозаверяющий сертификат SSL — это сертификат, подписанный лицом, которое его создало, а не доверенным центром сертификации. Самозаверяющие сертификаты могут иметь тот же уровень шифрования, что и доверенный CA-подписанный SSL-сертификат.

Самозаверяющие сертификаты, признанные действительными в любом браузере. Если вы используете самозаверяющий сертификат, веб-браузер покажет посетителю предупреждение о том, что сертификат веб-сайта невозможно проверить.

Самозаверяющие сертификаты в основном используются для целей тестирования или внутреннего использования. Вы не должны использовать самозаверяющий сертификат в производственных системах, которые подключены к Интернету.

Шаг 6 – Переключение на постоянное перенаправление

Если перенаправление работает правильно, и вы хотите разрешить только шифрованный трафик, вам следует снова изменить файл нешифрованного виртуального хоста Apache и сделать перенаправление постоянным.

Откройте файл конфигурации серверного блока еще раз:

Найдите добавленную нами строку . Добавьте в эту строку атрибут , который изменяет тип перенаправления с временного перенаправления 302 на постоянное перенаправление 301:

/etc/apache2/sites-available/000-default.conf

Сохраните и закройте файл.

Проверьте конфигурацию на ошибки синтаксиса:

Когда вы будете готовы, перезапустите Apache, чтобы сделать перенаправление постоянным:

Подписание SSL-сертификатов

Получить подписанный сертификат, когда имеется закрытый ключ и запрос на подпись можно несколькими способами: воспользоваться услугой авторитетных центров сертификации, отправив им запрос (CSR-файл) и получив в ответ готовый сертификат *.crt. Либо можно сделать сертификат самоподписанным. Т. е. подписать его тем же ключом, который использовался при создании файла CSR. Для этого следует выполнить команду:

$ openssl x509 -signkey server.key -in server.csr -req -days 365 -out server.crt

Здесь опция -days указывает количество дней, в течение которых выпускаемый сертификат server.crt будет действителен. В данном случае на протяжении одного года.
Также можно создать самоподписанный сертификат из имеющегося закрытого ключа без использования CSR-файла. Но в этом случае нужно вводить информацию CSR-запроса:

$ openssl req -key server.key -new -x509 -days 365 -out server.crt

Параметр -x509 задаёт формат генерируемого сертификата. Он является самым распространённым и используется в большинстве случаев. Опция -new позволяет запрашивать информацию для запроса у пользователя.

Важно отметить, что сертификаты, подписанные авторитетными центрами сертификации известны веб-браузерам. Самоподписанные сертификаты необходимо импортировать в хранилище доверенных сертификатов веб-браузера вручную

Поскольку соединения с доменами, обслуживаемыми такими сертификатами по-умолчанию блокируются.

Самоподписанный сертификат SSL

В понимании профессиональных IT-специалистов самоподписанный сертификат SSL представляет собой криптографический протокол, формируемый для отдельного IP-адреса либо персонального домена. Он также имеет альтернативные наименования – self-signed, самозаверенный, самоизданный.

Практически каждый самоподписанный сертификат SSL обладает следующими преимуществами:

  1. Не требуется оплата.
  2. Полная доступность. Получать бесплатный SSL-сертификат такого типа может всякий пользователь, владеющий зарегистрированным доменом.
  3. Нет надобности в обращении к компании, поставляющей услуги. Никаких задержек с ответами техподдержки или консультациями в центре сертификации.
  4. Быстрота процедуры. Вся последовательность действий нетрудная, когда известная специфика действий и есть навык использования особого софта. Также нужен опыт работы с SSL-библиотеками. К примеру, под Windows следует задействовать консоль PowerShell либо криптографическое хранилище OpenSSL.
  5. Разрешается создавать самоизданный сертификат SSL в любых количествах.

Некоторым здесь кажется достаточным изучение особенностей self-signed сертификатов. Однако, должны непременно рассматриваться отрицательные моменты.

Недостатки такие:

  1. Отсутствует надёжная защита. У браузеров нет доверия, поскольку самоподписанный сертификат SSL выдаются частниками или неизвестными юрлицами, а не специализированными центрами.
  2. Присутствует опасность потери данных. Реально утратить как собственную информацию, так и персональные пользовательские данные. Они теряются непосредственно с web-сайта, имеющего бесплатный SLL-сертификат.
  3. Посетители ресурса пугаются. Если человек, гуляющий по Всемирной паутине, заходит на интернет-страницу, где установлен самоизданный сертификат SSL, то видит браузерное предупреждение. Обязательно число посетителей сокращается, ведь готовность к совершению определённых действий логичным образом снижается. Все опасаются мошеннических ресурсов.
  4. Реальность ошибок в процессах оформления, а также отображения SSL-сертификата. Они появляются при неправильном создании набора правил сетевого взаимодействия.

Когда требуется проведение тестирования внутренних ресурсов фирмы, но возможности или желания создавать доверенные сертификаты нет, возможно создавать самоподписанный сертификат SSL.

Хотя даже при этом обстоятельстве остаются риски. У крупной корпорации здесь будут значительные временные и трудовые затраты, так как следует качественно оптимизировать работу.

Сотрудникам нужно объяснять процедуры и схематику действий для адекватной реакции на браузерное предупреждение об опасности. При взвешенной оценке получается вывод – самоизданный сертификат SSL нежелательно применять на современных сайтах.

Недостатки платных SSL-сертификатов

Отрицательных моментов крайне мало. Основные недостатки платных SSL-сертификатов:

1. Услуга платная – приходится ежегодно выплачивать суммы от 1 000 примерно до 16 000. Все виды платных SSL-сертификатов различаются свойствами и количеством защищаемых доменов, поэтому цены разные.

2. Случается затяжка оформления – каждый вариант характеризуется своими особенностями регистрации. Так, выпуск DV SSL почти моментальный в случае быстрого подтверждения клиентом своих данных.

3. Получения OV SSL нужно ждать до 2–3 суток, а EV SSL заказчик получает не ранее чемчерез 5 суток. Криптографический протокол для коммерческих web-сайтов требует подтверждения легальности бизнес-деятельности.

  • Лучшие курсы по SEO продвижению
  • Лучшие книги по SEO

Заключение

Я постарался рассказать подробно и понятно о полной настройке ELK Stack. Информацию в основном почерпнул в официальной документации. Мне не попалось более ли менее подробных статей ни в рунете, ни в буржунете, хотя искал я основательно. Вроде бы такой популярный и эффективный инструмент, но статей больше чем просто дефолтная установка я почти не видел. Буквально одна на хабре попалась с какой-то более ли менее кастомизацией.

Какие-то проверенные моменты я не стал описывать в статье, так как посчитал их неудобными и не стал использовать сам. Например, если отказаться от logstash и отправлять данные с beats напрямую в elasticsearch, то на первый взгляд все становится проще. Штатные модули beats сами парсят вывод, устанавливают готовые визуализации и дашборды в Kibana. Вам остается только зайти и любоваться красотой :) Но на деле все выходит не так красиво, как хотелось бы. Кастомизация конфигурации усложняется. Изменение полей в логах приводит к более сложным настройкам по вводу этих изменений в систему. Все настройки поступающей информации переносятся на каждый beats, изменяются в конфигах отдельных агентов. Это неудобно.

В то же время, при использовании logstash, вы просто отправляете данные со всех beats на него и уже в одном месте всем управляете, распределяете индексы, меняете поля и т.д. Все настройки перемещаются в одно место. Это более удобный подход. Плюс, при большой нагрузке вы можете вынести logstash на отдельную машину.

Я не рассмотрел в своей статье такие моменты как создание визуализаций и дашбордов в Кибана, так как материал уже и так получился объемный. Я устал писать эту статью :) Смотрите остальные мои материалы по данной теме. Там есть примеры.

Так же я не рассмотрел такой момент. Logstash может принимать данные напрямую через syslog. Вы можете, к примеру, в nginx настроить отправку логов в syslog, минуя файлы и beats. Это может быть более удобно, чем описанная мной схема. Особенно это актуально для сбора логов с различных сетевых устройств, на которые невозможно поставить агента, например mikrotik. Syslog поток так же можно парсить на ходу с помощью grok. Отдельно надо рассмотреть автоочистку старых индексов в elasticsearch.

Подводя итог скажу, что с этой системой хранения логов нужно очень вдумчиво и внимательно разбираться. С наскока ее не осилить. Чтобы было удобно пользоваться, нужно много всего настроить. Я описал только немного кастомизированный сбор данных, их визуализация — отдельный разговор. Сам я постоянно использую и изучаю систему, поэтому буду рад любым советам, замечаниям, интересным ссылкам и всему, что поможет освоить тему.

Все статьи раздела elk stack — https://serveradmin.ru/category/elk-stack/.

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: