Настройка собственного почтового сервера

Переключение на новый сервер

Самый важный и ответственный этап переноса почтового сервера. Здесь нужно еще раз хорошенько все проверить, убедиться, что все работает нормально. Непосредственно перед переключением на новый сервер, можно еще раз накатить изменения почтовой базы без остановки старого. Это позволит максимально уменьшить время простоя. Когда все готово, останавливаем службы dovecot и postfix почтового сервера. После этого сразу же запускаем синхронизацию каталогов между старым и новым сервером. Мы накатываем все изменения почтовой базы, делая ее полностью актуальной в новом сервере. Для этого надо добавить ключ —delete к rsync.

# /usr/bin/rsync --delete -av root@10.1.4.22:/data/mail /data

Важно не перепутать источник с приемником. Сначала идет старый сервер, потом новый

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

Ждёте окончания синхронизации. Она должна быть не долгой, так как перед остановкой почтового сервера вы и так накатили все изменения. Обычно несколько минут занимает процесс финального копирования. Когда он закончен, выключаете старый сервер, убираете его из автозагрузки гипервизора. На новом сервере меняете IP на адреса старого сервера и перезагружаете его. Можно и не перезагружать, но я для проверки всегда перезагружаю. Можно не менять IP адрес, если у вас все завязано на dns имена, отредактируйте dns запись. Но я обычно все же меняю ip, так надежнее. Обязательно найдется какое-нибудь старое оборудование, типа сканера, где адрес указан в виде ip адреса и т.д. Эти лишние проблемы потом не нужны. Лучше все сделать максимально незаметно и надежно.

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

Бывает, что не все идет гладко. У меня были ситуации, когда после перехода уже на новый сервер, начинались проблемы, которые предусмотреть заранее было нельзя. Новое хранилище начинало тормозить или возникали еще какие-то проблемы. Например, с блокировками на nfs. Вы это не проверили заранее. С работой dovecot на nfs есть свои нюансы. Если вы понимаете, что оставить в работе новый сервер нельзя и надо откатываться, то нужно опять синхронизировать почтовую базу, если для вас важна та корреспонденция, которая была доставлена в то время, как поработал новый сервер. Для этого останавливаете почтовые службы на новом сервере, меняете на нем ip, запускаете старый и выполняете синхронизацию в обратном порядке — с нового на старый. Не ошибитесь в параметрах rsync! После этого оставляете старый сервер в работе, а с новым спокойно разбираетесь и готовите его еще раз к переносу.

Вот, в принципе, и все по переносу почтового сервера из моей практики. Я их переносил штук 10 за все время админства. Можно сказать руку набил.

Что нужно знать перед началом работы

• Предполагаемое время для завершения: 10 минут для настройки пакета миграции. Однако общее время для завершения миграции зависит от количества почтовых ящиков, включенных в каждый пакет миграции.

• Для выполнения этих процедур необходимы соответствующие разрешения. Сведения о необходимых разрешениях см. в статье Подраздел «Разрешения перемещения и миграции почтовых ящиков» в разделе Recipients permissions.

• Гибридное развертывание настраивается между локальными организациями и организациями Exchange Online.

• Если используется Exchange 2013, на локальных серверах клиентского доступа Exchange 2013 включите прокси-службу репликации почтовых ящиков (MRSProxy).

• Сведения о ярлыках клавиатуры, которые могут применяться к процедурам в этом разделе, см. в разделе Клавишные ярлыки для центра администрирования Exchange клавиатуры.

• Лицензия Microsoft 365 или Office 365 Exchange должна быть назначена только после завершения миграции. Затем у вас есть 30 дней, чтобы назначить лицензию.

Совет

Возникли проблемы? Обратитесь за помощью к участникам форумов Exchange. Посетите форумы в Exchange Server, Exchange Onlineили Exchange Online Protection.

Конечные точки миграции для перемещения почтовых ящиков (между лесами и удаленного)

Конечные точки миграции используются для перемещения межлесных почтовых ящиков, а удаленный почтовый ящик перемещается между Exchange и Microsoft 365 или Office 365 в гибридных развертываниях. Не используйте конечные точки миграции для локального перемещения почтовых ящиков.

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

• Для перемещения почтовых ящиков между лесами требуется конечная точка миграции ExchangeRemoteMove.

• Перенос переноса почтовых ящиков в гибридных организациях (от Exchange до Microsoft 365 или Office 365) требует конечной точки миграции ExchangeRemoteMove в качестве источника пакета миграции.

• Перенос переноса почтовых ящиков с offboarding в гибридных организациях (от Microsoft 365 или Office 365 до Exchange) требует конечной точки миграции ExchangeRemoteMove в качестве цели пакета миграции.

Конечные точки миграции можно создавать в Центре администрирования Exchange и с помощью командлета New-MigrationEndpoint в командной консоли Exchange.

Шаг 2. Подключение Microsoft 365 или Office 365 систему электронной почты

Конечная точка миграции содержит параметры и учетные данные, необходимые для подключения локального сервера, на котором размещены почтовые ящики, переносимые с помощью Microsoft 365 или Office 365. Конечная точка миграции также определяет, сколько почтовых ящиков необходимо переносить одновременно. Для прямой миграции создается конечная точка миграции мобильного Outlook.

1. Перейдите в Центр администрирования Exchange.

2. В Центр администрирования Exchange выберите Получатели > Миграция.

3. Выберите дополнительные конечные точки миграции > значков.

4. На странице Конечные точки миграции выберите новый значок .

5. On the Select the migration endpoint type page, choose Outlook Anywhere > Next.

6. На странице Введите учетные данные локальной учетной записи введите данные в следующие поля:

   • Адрес электронной почты. Введите адрес электронной почты любого пользователя в локальной Exchange организации, которая будет перенесена. Microsoft 365 или Office 365 протестировать подключение к почтовому ящику этого пользователя. Убедитесь, что этот почтовый ящик не скрыт от списков адресов.

     

     

     

     

     

     

     

     

     

     

   • Учетная запись с привилегиями. Введите имя пользователя (формат домена\имя пользователя или адрес электронной почты) для учетной записи, которая имеет необходимые административные разрешения в локальной организации. Microsoft 365 или Office 365 будет использовать эту учетную запись для обнаружения конечной точки миграции и проверки разрешений, присвоенных этой учетной записи, пытаясь получить доступ к почтовому ящику с указанным адресом электронной почты.

   • Пароль учетной записи с привилегиями. Введите пароль для учетной записи с привилегиями, которые является учетной записью администратора.

7. Нажмите кнопку Далее и сделайте одно из следующего:

   • Если Microsoft 365 или Office 365 успешно подключается к исходным серверам, отображаются параметры подключения. Нажмите кнопку Далее.

   • Если тестирование подключения к исходному серверу не будет пройдено, введите следующие сведения:

   • Exchange: Введите полное доменное имя (FQDN) для локального Exchange Server. Это имя для сервера почтовых ящиков. Например, EXCH-SRV-01.corp.contoso.com.

   • Прокси-сервер RPC. Введите FQDN для прокси-сервера RPC для Outlook любом месте. Как правило, прокси-сервер является таким же, как Outlook веб-адрес (ранее известный как Outlook Web App). Например, mail.contoso.com, который также является URL-адресом прокси-сервера, который Outlook для подключения к Exchange Server

8. На странице Ввод общих сведений введите имя конечной точки миграции, например Test5-endpoint. Leave the other two boxes blank to use the default values.

9. Выберите Создать для создания конечной точки миграции.

   Чтобы проверить подключение Exchange Online к локальному серверу, можно выполнить команду из примера 4 для командлета Test-MigrationServerAvailability.

SMTP: Установка postfix

postfix это один из наиболее используемых SMTP серверов, поскольку он стабильный, лёгкий, масштабируемый и высоко настраиваемый. Установка postfix может быть выполнена использованием apt-get.

:~# apt-get install postfix

Во время установки задаются тип почтового сервера и доменное имя.

Так как почтовый сервер будет отправлять письма напрямую к месту назначения, то нужно использовать «Интернет-сайт».

Также задаём доменное имя почтового сервера. Эта настройка определяет, что все письма, приходящие с этого почтового сервера, будут иметь @example.tst в качестве домена отправителя.

Конфигурационные файлы postfix размещены в /etc/postfix. Важны следующие конфигурационные файлы. Некоторые из них могут отсутствовать и их нужно создать вручную.

• transport: В первую очередь используется для определения, как почта должна быть направлена в направлении конкретного домена назначения. Это тот случай, когда кому-то может быть потребуется отправлять почту, предназначенную для домена XYZ.com, напрямую на IP адрес X.Y.Y.X независимо от каких-либо результатов запросов DNS.
• access: Может быть использован в целях безопасности, например для блокирования отправителей/получателей и их доменов.
• aliases: Используется для задания пользовательских псевдонимов. Например, почта отправленная пользователю userA должна быть принята пользователем userB, а также пользователем userC.
• main.cf: Это конфигурационный файл для postfix.

Шаг 1. Подтверждение владения доменом

Во время миграции для создания электронного адреса для нового почтового ящика используется простой протокол передачи почты (SMTP) каждого локального почтового ящика Microsoft 365 или Office 365 почтовый ящик. Для запуска переноса перереза локального домена должен быть проверен домен в Microsoft 365 или Office 365 организации.

1. Вопишитесь в Microsoft 365 или Office 365 с вашей учетной записью или учебной записью.

2. Выберите Настройка > Домены.

3. На странице Домены щелкните Добавить домен, чтобы запустить мастер домена.

4. На странице Добавить домен введите доменное имя, которое вы используете для локальной организации Exchange (например, Contoso.com), а затем нажмите кнопку Далее.

5. On the Verify domain page, select either Sign in to GoDaddy (if your DNS records are managed by GoDaddy) or Add a TXT record instead for any other registrars > Next.

6. Следуйте инструкциям для своего поставщика услуг размещения DNS. Для подтверждения владения обычно используется запись TXT.

   

   

   

   

   

   

   

   

   

   

   Инструкции по подключению домена можно также найти в записях добавить DNS.

   После добавления записи TXT или MX подождите около 15 минут, прежде чем переходить к следующему шагу.

7. В мастере доменов Office 365 выберите Готово, можно проверить. Появится страница проверки. Нажмите кнопку Завершить.

   Если проверка не будет пройдена, подождите некоторое время и повторите попытку.

   Не переходите к следующему шагу в мастере доменов. Вы подтвердили владение доменом локальной организации Exchange и можете продолжать миграцию электронной почты.

Установка системы и начальная конфигурация

В гостевой ОС вполне можно отказаться от раздела подкачки, особенно если назначить ВМ достаточное количество оперативки, а datastore гипервизора находится на SSD. Я взял Debian 10, процесс установки полностью стандартный за исключением разметки диска. Имя сервера задаем mail, домен example.com. Система ставится в минимальной конфигурации. В разметке дисков я сделал первый раздел под /boot и второй раздел с шифрованием:

После установки системы я делаю несколько базовых вещей. Удаляю созданного при установке пользователя командой .

Задаю статический адрес, если это не было сделано во время установки. Для этого правим файл

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

Для применения изменений выполняем команду (не забываем здесь заменить название сетевого интерфейса на свое):

Чтобы не углубляться в настройку домашних роутеров, VPN туннель мы будем делать сразу с почтового сервера до VPS и завернем туда весь трафик. Поэтому имеет смысл поменять DNS сервера на публичные. Для этого правим файл , конечный вид которого примет вид:

IPv6 я тоже отключаю, для этого в конец файла добавляю строку:

Чтобы параметр применился выполняем команду:

Проверить, отключился ли IPv6 довольно легко. Для этого нужно просмотреть вывод нижеследующей команды на наличие ipv6 адресов:

Устанавливаем ssh и wget:

Включаю логин по паролю для root по SSH, для этого в файле добавляем строку . Применяем изменения:

Коннектимся к серверу по ssh и едем дальше.

Настройка почтового сервера

Чтобы не заниматься курением конфигов, а результат был предсказуем ‒ я сделал скрипт, который автоматизирует 90% всего процесса из вышеупомянутого гайда с некоторыми отличиями:

• Я не хочу ставить на почтовый сервер ресурсоемкий Nextcloud, вместо него я буду использовать Rainloop

• Подрежем еще несколько мета-тегов: X-Mailer, X-Originating-IP, X-PHP-Originating-Script, Mime-Version. При этом в оригинальном гайде фильтрация конфигурируется в master.cf, а у меня в main.cf

Скрипт устанавливает необходимые пакеты, конфигурирует apache, БД, конфигурирует почтовые службы и на выходе получается практически готовый к употреблению почтовый сервер. При этом я пока не стал включать в скрипт генерирование SSL и DKIM, сделаем это руками чуть ниже.

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

Скачиваем и распаковываем скрипт:

Всего в каталоге 3 файла:

• — основной скрипт конфигурирования сервера

• — скрипт создания почтового юзера

• — скрипт смены пароля для существующего почтового юзера

Запускаем . Скрипт попросит ввести следующие данные: имя хоста почтового сервера (в этом гайде это просто mail), имя домена, который был ранее зарегистрирован (например, example.com), IP адрес почтового сервера в локальной сети. Имя хоста + домен как раз образуют полное имя mail.example.com. По завершению работы скрипта почтовые сервисы остаются в выключенном состоянии, т.к. перед запуском надо сгенерировать SSL сертификаты и DKIM. Так же по завершению будет отображен админский пароль от БД. Этот пароль нужно вставить в скрипты и вместо слова PASSWORD, см в файлах вторую строку:

Перенос почты на Google

«Google Apps для бизнеса» имеет бесплатный 30-дневный тестовый период

Обратите внимание, что для полноценной работы вам необходимо будет приобрести пакет «Google Apps для бизнеса»

1. На странице начала работы с «Google Apps» в блоке «О себе» заполните регистрационную информацию, затем нажмите кнопку «Далее».
2. Выберите пункт «Использовать приобретенное мной имя домена», укажите домен, обслуживание почты которого нужно перенести на Google, и нажмите «Далее».
3. Создайте аккаунт администратора Google Apps. Для этого в блоке «Имя пользователя» укажите имя почтового ящика, например, «admin», задайте к нему пароль и примите условия использования сервиса.
4. Авторизуйтесь от имени созданного пользователя, после чего вы попадете в консоль администратора Google. Для подтверждения права собственности на домен выберите способ «Добавить запись TXT или CNAME» и следуйте подсказкам Google.
5. Скопируйте предоставленную вам TXT-запись, перейдите к вкладке Панели управления и укажите значение записи в поле «Подтвердить домен». В этот момент автоматически изменятся MX-записи домена на записи Google.
6. Вернитесь на страницу подтверждения прав на домен в Google Apps, пройдите по оставшимся шагам инструкции и нажмите «Подтвердить».

Теперь все необходимые настройки DNS для домена указаны, почта начнет приходить на почтовый сервис Google в течение нескольких часов, как только информация о зоне вашего домена обновится в кеше DNS. Вам остается настроить ваш аккаунт в Google Apps.

Использование почты на внешних сервисах

Для работы с почтой домена вы можете использовать как веб-интерфейс сервисов Яндекс, Mail.Ru или Google, так и стандартные протоколы работы с почтой (POP3/IMAP, SMTP).

Отмена использования внешних почтовых сервисов для домена

Чтобы почта вашего домена стала вновь приходить на наш почтовый сервер, необходимо отменить ее перенос. Для этого достаточно нажать кнопку «Вернуть обратно» в разделе «Перенос почты на внешние сервисы».

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

Выбор и запуск приложения почтового сервера

Конечно, хостинг должен позволять устанавливать программное обеспечение. Можно использовать любое подходящее приложение для почтового сервера. Например, есть бесплатный hMailServer для Windows, который предоставляет все необходимые функции с минимальным использованием ресурсов. Для систем на базе UNIX существует множество бесплатных почтовых серверов, таких как Exim Internet Mailer или iRedMail.

Инициализация

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

• Домен и пользователиНужно добавить домен и начальный набор пользователей почтового сервера.

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

• Подпись сообщенийДалее, следует настроить DKIM. Нужно указать полученные выше приватный ключ и селектор. Кроме того, методы заголовка и тела должны быть установлены на «расслабленный», алгоритм подписи должен быть установлен на «SHA256», иначе на некоторых SMTP серверах не проходит проверка (например, google).

• Защита от спамаНаконец, нужно настроить антиспам-проверку специальными узлами черных списков, такими как spamhaus.org, чтобы защитить пользователей почтового сервера от нежелательных сообщений.

Протоколы электронной почты

Нужно настроить три протокола электронной почты, которые необходимы для её отправки и получения.

SMTP

SMTP используется для приема входящей и исходящей почты с/на другие почтовые серверы. И это позволяет пользователям домена отправлять свои сообщения.

• 25 портЭтот порт необходим для управления входящими подключениями от других почтовых серверов. Метод безопасности следует установить в STARTTLS.

• 587 портОн нужен для почтовых клиентов собственного почтового сервера. Метод безопасности следует установить в STARTTLS.

• 465 портОн не является официальным и может потребоваться для старых почтовых клиентов. И метод безопасности следует установить в SSL/TLS.

  

  

  

  

  

  

  

  

  

  

POP3, IMAP

POP3 и IMAP используются отдельными почтовыми клиентами, такими как Outlook на ПК или любой почтовый клиент на мобильных телефонах. Это позволяет пользователям домена управлять своими сообщениями.

Порт 993 следует использовать для защищенных соединений IMAP, а порт 995 — для POP3. Для обеспечения совместимости с большинством клиентов метод безопасности следует установить в SSL/TLS (не STARTTLS).

Также можно настроить порты 143 для IMAP и 110 для POP3, но они не шифруются и сейчас их уже мало кто использует.

Проверка

Итак, когда все настроено, нужно протестировать почтовый сервер, отправив письмо кому-нибудь из списка пользователей. Кроме того, в некоторых почтовых приложениях есть функция самодиагностики (см. ниже пример от hMailServer).

Теперь пора проверить отправку на внешний адрес.

Аккаунт Gmail.com

Если есть учетная запись Gmail.com (что наверняка), можно отправить тестовое письмо на свой адрес Gmail. Затем открываем свою электронную почту в браузере и нажимаем «Показать подробности».

Если есть «подписано: домен», подпись DKIM настроена правильно. Если есть «отправлено по почте: домен», SPF в порядке.

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

Также, в Outlook можно видеть те же заголовки в свойствах сообщения.

Специальные онлайн-сервисы

Существует множество онлайн-сервисов, которые могут проверять отправку электронной почты. Ниже приведены некоторые из них.

• AppMailDevЭтот сервис позволяет тестировать конфигурацию почтового сервера, такую как DKIM и SPF, отправляя электронное письмо на указанный сгенерированный почтовый адрес. Нужно просто следовать инструкциям на экране и результаты теста будут отображены там же.

• DKIMValidatorПредоставляет те же функции, что и предыдущая служба. Результаты тестирования будут отправлены на адрес отправителя.

• PowerDMARCЭтот сервис предоставляет только облегченную проверку всех атрибутов, но у него есть удобные инструменты, указанные в ссылках выше.

Итак, если всё настроено правильно, но сервер присутствует в чёрных списках спама, нужно внести его в белый список.

Примеры

В этом разделе приведено несколько примеров возможного использования сценария Prepare-MoveRequest.ps1.

Пример: Один пользователь связанной почты

В этом примере содержится один пользователь связанной почты в локальном лесу, если между удаленным лесом и местным лесом существует доверие к лесу.

1. Выполните следующие команды, чтобы получить учетные данные локального и удаленного лесов.

2. Выполните следующую команду, чтобы передать эти учетные данные в параметры LocalForestCredential и RemoteForestCredential в скрипте Prepare-MoveRequest.ps1.

Пример. Конвейеризация

В этом примере иллюстрируется поддержка конвейерного режима при указании списка идентификаторов почтового ящика.

1. Выполните следующую команду.

2. Запустите следующую команду, чтобы передать сведения о учетных данных параметру RemoteForestCredential в Prepare-MoveRequest.ps1 скрипте.

   

   

   

   

   

   

   

   

   

Пример. Использование файла .csv для массовой создания пользователей почты

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

Например, CSV-файл может иметь следующее содержимое:

В этом примере .csv файл для массовой создания целевых пользователей почты.

1. Выполните следующую команду, чтобы получить учетные данные леса.

2. Выполните следующую команду, чтобы передать эти учетные данные в параметр RemoteForestCredential в сценарии Prepare-MoveRequest.ps1.

Перенос данных из Gmail

Настройка и выполнение переноса данных из Gmail

1. Войдите в Консоль администратора Google.

   Для входа используйте (он не заканчивается на @gmail.com).

2. На главной странице консоли администратора выберите Перенос данных.
3. Нажмите Настроить перенос данных.
4. В списке Источник переноса выберите Gmail.
5. Нажмите Начать.
6. В разделе Дата начала переноса оставьте значение по умолчанию или .
7. В разделе Параметры переноса оставьте значения по умолчанию или исключите ненужные данные.
8. Нажмите Выбрать пользователей.
9. Нажмите Добавить пользователя.
10. В поле Исходный адрес электронной почты введите адрес пользователя в Gmail.
11. В поле Адрес электронной почты Google Workspace начните вводить новый адрес пользователя в Google Workspace и выберите нужный вариант из списка подсказок.
12. Нажмите Авторизация.
    • Владельцу почтового ящика Gmail потребуется войти в аккаунт.
    • Владелец аккаунта Gmail должен одобрить запрос на просмотр почты и управление ею, нажав Разрешить.
13. Скопируйте полученный код и вставьте его в поле Код авторизации.

    Примечание. Код действует в течение 10 минут, после чего аннулируется.

14. Нажмите Начать.
15. Чтобы перенести данные другого пользователя, повторите указанные выше действия.

Советы по переносу данных

• Если у вас есть вопросы о процедуре переноса, прочитайте ответы на часто задаваемые вопросы.
• Чтобы изменить настройки переноса, сначала его необходимо отменить. Подробнее о том, …
• Вы можете изменить скорость переноса. Подробнее…
• Вы можете отслеживать статус переноса данных для отдельного пользователя, а также запросить отчет на уровне домена. Подробнее…
• Если во время переноса возникают проблемы, ознакомьтесь со статьей Как устранять неполадки со службой переноса данных.

Заключение

Для того, чтобы любые работы на prod сервере прошли успешно, я всегда соблюдаю несколько правил:

1. Никогда не тороплюсь. Если реально нет необходимости спешить, я всегда довожу до руководства, что спешка не нужна. Она вредит и мешает все сделать хорошо. Пусть лучше я спокойно неделю или две подготовлюсь, все обдумаю, проверю и перенесу без проблем, нежели я буду спешить для соблюдения бессмысленных сроков.
2. Тщательно все проверяю и перепроверяю. Делаю все максимально незаметно. Если простой ожидается маленький, не шлю никому никаких уведомлений. Если вы предупредите, что будут работы с почтовым сервером, на следующие дни обязательно кто-то нажалуется, что после переноса все сломалось. Это мешает снимать реальные обратные связи. Когда никто не знает о переносе, отзывы будут только на реальные проблемы, а не надуманные.
3. У меня всегда есть запасной план на случай, если что-то пойдет не так. Всегда под рукой актуальные бэкапы и подменные системы. Я точно знаю, что буду делать, если новый сервер не будет введен в эксплуатацию.

Этого достаточно, чтобы успешно проводить любые работы на серверах. Главное, все запланировать заранее, чтобы не было спешки. А как вы планируете масштабные обновления или переносы prod серверов?

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.

Что даст вам этот курс:

• Познакомитесь с Terraform.
• Изучите систему управления конфигурацией Ansible.
• Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
• Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
• В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .