Server admin - авторский блог системного администратора

Публикация баз 1С на веб сервере

Идем на виртуалку с windows и работаем там с 1С. Кстати, если хотите обойтись вообще без windows, то есть возможность настроить публикацию баз 1С на linux на примере Centos.

Для начала устанавливаем технологическую платформу и не забываем выбрать Модули расширения веб-сервера.

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

Установка и настройка Apache 2.4 в Windows

Теперь устанавливаем apache 2.4. С ним опубликовать базы 1С проще и быстрее, чем с iis. Качаем apache отсюда — https://www.apachelounge.com/download/

Если у вас не установлен Visual C++ Redistributable for Visual Studio 2015-2019, то скачайте дистрибутивы там же. Бинарники apache скачали, теперь распакуем их в папку C:/apache24/. Затем идем в конфигурационный файл apache C:\Apache24\conf\httpd.conf, открываем его блокнотом и изменяем там несколько параметров:

ServerName localhost:80
ErrorLog "|C:/apache24/bin/rotatelogs.exe -l C:/apache24/logs/errorlog.%Y-%m-%d.log 2592000"

Последняя строка это автоматическая ротация логов. Рекомендую ее сразу настроить, а не откладывать на потом. Если у вас по какой-то причине нет возможности использовать стандартный порт 80, потому что он занят кем-то другим, то можно использовать любой другой, например 81. Я всегда так и делал раньше. Но с недавних пор это стало приводить к ошибке, так как после публикации баз 1c через reverse proxy с https, стали вылезать ссылки вида https://1c.server.ru:81. Подобные ссылки невозможно открыть. Это приводит к ошибкам в работе некоторых разделов базы, где эти ссылки вылезают. Подробнее этот момент я рассмотрю ниже, в разделе с возможными ошибками.

Если вы настраиваете apache на Windows Server, то скорее всего 80-й порт у вас будет занимать Служба веб-публикаций (World Wide Web Publushing Service) или W3SVC. Ее можно остановить и отключить.

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

netstat -ao

Дальше через диспетчер задач смотрите, какой процесс имеет указанный pid. В моем случае это apache. Если это какой-то системный процесс, у него будет pid 4.

Итак, конфиг apache отредактировали, порт 80 указали. Теперь установим apache 2.4 как службу windows

Для этого открываем командную строку от администратора (это важно), переходим в каталог C:\Apache24\bin и выполняем:

httpd.exe -k install

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

Errors reported here must be corrected before the service can be started.
AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name, using fe80::955f:6a46:c404:c1f7. Set the 'ServerName' directive globally to suppress this message.

Переходим в оснастку windows Службы и запускаем Apache2.4.

Убедимся, что веб сервер нормально работает. Для этого в браузере достаточно открыть страницу http://localhost.

Вы должны увидеть сообщение It works! Если видите, то все в порядке.

Дальше выполняем непосредственно публикацию базы 1С через web сервер apache. Открываем базу через Конфигуратор, выбираем Администрирование -> Публикация на веб-сервере. В качестве каталога можно указать тот же, где лежит сам файл с базой.

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

После этого можно зайти в браузере по адресу http://localhost/buh3 и увидеть локальную файловую базу, которую мы только что опубликовали.

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

Настройка нод криптовалют

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

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

Знаю, сколько и какая нода потребляет ресурсов, где и на чем можно сэкономить. Цену не озвучиваю, все индивидуально. Обращайтесь, если вам нужна помощь с нодами крипты. Я смогу помочь.

Подключение через Платформу 1С:Предприятие к базе 1С, опубликованной в веб

Упомяну одну важную вещь, про которую я сам узнал не сразу. С опубликованной в web базой 1С не обязательно работать через браузер. Можно подключиться через обычную платформу, если она у вас установлена на компьютере. Причем все отлично заработает даже с дополнительной basic auth в виде еще одной авторизации.

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

При подключении к такой базе вам сначала нужно будет ввести пароль на доступ к веб сайту, а потом уже появится авторизация самой 1С. Удобно выходит. И субъективно кажется, что через платформу 1С работать с опубликованной базой немного быстрее. Быстрее отклик на действия пользователя.

Повторное включение архивного почтового ящика

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

Повторное включение архивного почтового ящика с помощью Центра администрирования Exchange

Перейдите к разделу Получатели > Почтовые ящики.
Выберите почтовый ящик.
В области сведений в разделе Личный архив нажмите кнопку Включить.
На странице Создание архива на месте нажмите кнопку ОК.

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

Как убедиться, что все получилось?

Чтобы убедиться, что вы успешно подключили отключенный архивный почтовый ящик к основному почтовому ящику пользователя, запустите следующую команду для получения свойств архива пользователя почтового ящика и проверьте значения, возвращенные для свойств ArchiveGuid и ArchiveDatabase.

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

Техническое обслуживание сайтов

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

Аренда выделенного сервера от 4000 р. в месяц. На сервер ставится гипервизор proxmox.
Создаются в базе 3 виртуальные машины: nginx_proxy, prod web сервер и dev сервер.
Приобретается у другого хостера виртуальная машина с большим диском для сервера мониторинга zabbix и бэкапов сайта с большой глубиной хранения изменений.
Пишется документация на все настроенное.

На сервере мониторинга настраиваются оповещения, мониторинг за всей инфраструктурой: базовые метрики серверов (процессор, память, диски, сеть), состояние дисков и рейда, web сервера, мониторинг бэкапов, сертификатов, доменов, доступность и скорость отклика сайтов, подключения по ssh и остальное по необходимости. По отдельной договоренности могу подключить ваши сервера к своему ELK Stack для более детального мониторинга и анализа состояния. Либо настроить вам собственный сервер для этого.

Для 100% уверенности в надежности бэкапов и возможности быстро на него переключиться рекомендую приобрести отдельно еще один сервер или виртуальную машину, куда периодически будет разворачиваться бэкап и проверяться. Это можно автоматизировать. В случае выхода из строя основного сервера, dns переключаются на резервный.

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

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

В арендуемом у хостера сервере стала расти температура жестких дисков. Если бы не информация из мониторинга, этого бы никто не заметил, пока не вышел из строя один из дисков. А с учетом постоянного перегрева, выйти из строя могли сразу несколько дисков.
У вас вышел из строя диск, вы просите тех поддержку хостинга заменить его, а они меняют не тот диск.
Разработчики что-то меняли на сайте, выключили кэширование и забыли его включить. Вместо обычных 300-500 мс сервер стал отдавать страницы за 2-3 сек. Низкая скорость сайта ухудшает ранжируемость сайта и конверсию. Мониторинг вас предупредит о низкой скорости отдачи страниц.
После очередного переезда или перезаливки базы сайта, забыли в задании бэкапа указать актуальную базу для бэкапа. В итоге у вас вообще нет бэкапа продуктовой базы. Нужна регулярная ручная проверка бэкапов, для того, чтобы быть максимально уверенным в том, что он актуален.
Месяц назад к вам на сервер через уязвимость залили вирус, который позаражал почти все исходники. Когда это заметили, не осталось версии бэкапа с незараженными файлами. Ручная чистка сайта очень трудозатратна. Если бы за сайтом регулярно следили и хранили бэкапы с большой глубиной изменений, проблем бы было значительно меньше.

В общем, примеров того, зачем нужна регулярная поддержка сайтов и серверов у меня много. Это все актуально, если сайт приносит деньги и его простой приведет к потере денег. Оправданность регулярной поддержки, минимизирующей простой, просчитывается достаточно просто. Кому-то это выгодно, кому-то нет. Посчитайте сами.

Какие бывают проблемы с работой в 1С через браузер

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

Так что некоторые вещи, которые обычно бухгалтера в небольших компаниях способны сделать сами, придется делать тому, кто обслуживает этот сервер. Но бонусом идет то, что на самих пользовательских компьютерах ничего настраивать не надо. Вы просто передаете пользователю адрес в интернете и учетные данные. И он начинает работать в базе 1с. Платформу ставить не надо, как и решать вопрос с лицензиями на клиентах.

Еще один нюанс, связанный с обменом между базами. После обновления платформы на сервере, он перестает работать через браузер. Возникает ошибка доступа к COM объекту. Чтобы это исправить, надо выполнить на сервере регистрацию comcntr.dll примерно так.

regsvr32 "C:\Program Files\1cv8\8.3.18.1208\bin\comcntr.dll"

Сделать это надо в cmd с правами администратора. И повторять каждый раз при обновлении платформы, не забывая указать путь к новой версии файла.

С недавних пор я столкнулся с новой для меня ошибкой при подобной публикации баз с использованием nginx и proxy_pass. Раньше я использовал отличный от 80-го порт в apache. Но периодически стали проскакивать ссылки при работе с опубликованной базой 1с примерно такого вида — https://1c.site.ru:81/ в случае, если вы используете 81-й порт. Запросы извне по этой ссылке уходят в никуда и возникают ошибки. На стороне клиента они выглядят так:

Uncaught TypeError: Cannot read property ‘toUpperCase’ of undefined on https://……./mod_main_loader.js

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

Ну и еще одно отмечу. Иногда apache зависает или начинает сильно тупить. Обычно после долгого аптайма в несколько недель. Я подробно не разбирался в проблеме. Предпочел просто перезапускать его раз в сутки ночью. Для этого сделал обычный bat файл и настроил запуск через планировщик Windows.

@echo off
sc stop "Apache2.4"
timeout 90
sc start "Apache2.4"

Понятно, что это грубый костыль, но проблему решает. Ночью все равно с 1С никто не работает. Это история не про отказоустойчивость, резервирование и работу 7/24/365.

Бэкап текущего сайта

Прежде чем подготовить подменный сервер, надо сделать бэкап сайта с текущего сервера. Тут я не буду ничего изобретать и показывать какие-то особые приемы. Все делается очень просто через rsync. Подробно его работу я рассказываю в статье — настройка бэкапа через rsync. С его помощью на сервер с бэкапами уезжают как исходники сайтов, так и дампы баз данных mysql. С базами тоже все просто — делаем обычный дамп через mysqldump. Если база большая, нужны инкрементные бэкапы — использую Percona XtraBackup.

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

#!/bin/bash

# Добавляю метку времени в имя файлов
date_time=`date +"%Y-%m-%d_%H-%M"`
# Директория, куда кладем архив
bk_dir='/mnt/backup/day'
# Директория с сайтами
inf_dir=/web/sites
# Директория, которая идет в архив
dir_to_bk='www'
# Пользователь БД
user='serveradmin'
# Пароль пользователя БД
password='passmysql*%'
# Исключения по расширениям файла
exclude_ext='--exclude='*.log' --exclude='*.tmp''
# Исключения по директориям
exclude_dir='--exclude='wp-content/cache/*''

# Дамп базы данных кладу в корень сайта
/usr/bin/mysqldump --opt -v --no-create-db serveradmin -u$user -p$password > $inf_dir/serveradmin.ru/www/mysql_serveradmin.ru_$date_time.sql
# Бэкаплю сайт вместе с дампом базы
/usr/bin/tar ${exclude_ext} ${exclude_dir} -czvf  $bk_dir/serveradmin.ru_$date_time.tar.gz -C $inf_dir/serveradmin.ru $dir_to_bk
# Удаляю из корня сайта дамп БД
/usr/bin/rm -rf $inf_dir/serveradmin.ru/www/mysql_serveradmin.ru_$date_time.sql

Дальше этот архив можно отправить в s3 с помощью rclone или чего-то подобного.

Если вам нет нужды класть дамп базы вместе с исходниками сайта, а так же если у вас сервер БД это отдельная машина, то бэкапы можно делать таким скриптом. Он положит дамп каждой базы в отдель

#!/bin/bash

for i in `mysql -uroot -p'password' -e'show databases;' | grep -v information_schema | grep -v Database`; 
    do 
	/usr/bin/mysqldump -uroot -p'password' $i | /usr/bin/gzip -c > /backup/mysql/`date +%Y-%m-%d`-$i.sql.gz;
    done

Архивы всех баз по отдельности будут сжаты и положены в директорию /backup/mysql. Не забудьте их потом почистить, чтобы не копились. Это относится как к дампам, так и архивам. Я обычно чищу их после того, как они уезжают на бэкап сервер. Часть копий остаются на исходном сервере, если есть возможность. Так можно оперативно что-то восстановить при необходимости, не обращаясь к бэкап серверу.

Чистим файлы стандартно через find. Удаляем все, что старше 7-ми дней.

/usr/bin/find /backup/mysql/ -type f -mtime +7 -exec rm {} \;

С бэкапами разобрались, переходим к восстановлению.

Доступ к файловой базе 1с через интернет в браузере

Теперь перемещаемся на виртуальную машину с nginx. Предварительно не забудьте добавить dns запись в каком-то домене, по которой вы будете ходить в базу через интернет. Она нам нужна, чтобы выпустить бесплатный tls сертификат, чтобы ходить в базу по https. Я не буду привязываться к какой-то конкретной операционной системе и рассказывать, как все делать именно в ней. Систему выбирайте на свой вкус. Настройка будет одинаковой. Нам нужны будут в системе 2 пакета: nginx и certbot. Установите их:

# yum install nginx certbot

или

# apt install nginx certbot

На данную виртуальную машину должны быть проброшены 80 и 443 порты с внешнего ip адреса. Как это будет сделано, зависит от ваших сетевых настроек. В случае с proxmox я настраиваю подобный проброс с самого хоста с помощью iptables. Пример настройки iptables читайте в отдельной статье. Там есть и про проброс. Не буду на этом задерживаться в статье про 1С.

Теперь нам нужно получить сертификат. Для этого запускайте в консоли certbot и следуйте инструкциям. Перед этим остановите nginx. Для быстрого получения сертификата certbot предлагает временно запустить свой веб сервер на 80-м порту.

# systemctl stop nginx
# certbot certonly

Подробно получение сертификата let’s encrypt с помощью certbot я рассматриваю в статье про . Результатом работы certbot должны быть tls сертификаты в директории /etc/letsencrypt/live. Используем их в настройке виртуального хоста nginx для публикации баз 1С. Создаем в директории /etc/nginx/conf.d/ конфиг 1c.site.ru.conf примерно следующего содержания. Взял его с рабочего сервера.

server {
    listen 443 ssl http2;
    server_name 1c.site.ru;
    access_log /var/log/nginx/1c-access.log;
    error_log /var/log/nginx/1c-error.log;

    ssl_certificate /etc/letsencrypt/live/1c.site.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/1c.site.ru/privkey.pem;

    location /.well-known/acme-challenge/ {
    root /tmp;
    }

    location / {
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/htpasswd.1c;
    proxy_pass http://10.10.10.11:80;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto https;
    }
}

server {
    listen 80;
    server_name 1c.site.ru;
    return 301 https://1c.site.ru$request_uri;
}

В данном случае 10.10.10.11 — локальный ip адрес виртуальной машины с windows, где опубликована база 1С через apache. Доступ к 1С сразу же закрыт отдельным паролем и механизмом веб сервера auth basic. Создадим файл с именем пользователя и паролем, указанным в конфиге.

# htpasswd -c /etc/nginx/htpasswd.1c user1c

Если у вас нет в системе утилиты htpasswd, то установите пакет httpd-tools. Она из него. user1c — имя пользователя. Пароль вам предложат задать в консоли.

Теперь можно запускать nginx и проверять доступ к базе 1с по https с дополнительной авторизацией. Так как в конфиге nginx настроен proxy_pass всех запросов через location / , то на самой виртуалке с 1С вы можете публиковать сколько угодно баз через алиасы, например /buh3, /zup3 и т.д. Все они будут автоматом направляться с nginx на apache. При этом на самом nginx конфигурацию менять не придется.

Вот и все. Можно относительно безопасно выставлять такую конструкцию в интернет. В случае необходимости можно настроить fail2ban, если кто-то надумает перебирать пароли или просто выполнять непонятные запросы к веб серверу с опубликованными базами. При желании в том же nginx с помощью директив allow и deny можно ограничить доступ к виртуальному хосту с базами на уровне ip адресов. Это на случай, если не умеете делать то же самое на фаерволе. В nginx проще и быстрее.

Не забудьте настроить автоматическое обновление tls сертификатов. Как это сделать, я рассказываю в статье с настройкой web сервера. Ссылку на нее я дал выше.

Бэкап баз 1С

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

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

Доступ к ней максимально ограничен. Она сама забирает все бэкапы к себе. С windows машины к ней доступа нет. Сделано это для простейшей защиты от шифровальщиков. Если какой-то вирус попадет на сервер и зашифрует базы 1С, я очень быстро смогу их восстановить из архивных копий, которые хранятся на этом же гипервизоре, только в другой виртуальной машине.

На windows сервере можно просто расшарить директорию с базами 1С, а на виртуалке для бэкапов подключить ее. Я обычно использую Linux систему для этого. В ней монтирую шару по smb. Как это сделать рассказываю в отдельной статье — Как быстро подмонтировать сетевой диск в Linux. После того, как подключили папку с базами 1С к бэкап серверу, можете делать с ними все, что угодно. Например, куда-то копировать с помощью rsync и сохранять изменившиеся базы. Подробно схему бэкапов с помощью rsync описываю тоже отдельно — настройка rsync для бэкапа. Обязательно одну копию держу локально на сервере с бэкапами, вторую отправляю куда-то в удаленный приемник. После этого шару отмонтирую. Она подключена только для копирования баз с windows машины на linux.

Так же для бэкапов вы можете использовать какое-нибудь S3 хранилище, например у того же Selectel. По моим недавним сравнениям по ценам там наиболее выгодные условия из известных хостеров. По крайней мере я дешевле не нашел. Заливать бэкапы в S3 можно с помощью утилиты rclone. У Selectel еще очень удобно сделано в плане настройки времени хранения данных в контейнерах. Я обычно создаю 3 разных контейнера:

Day — в него заливаются архивы каждый день. Срок хранения файлов в этом контейнере — 7 дней. Настраивается это штатно в панели управления. На стороне хоста, с которого заливаются данные, ничего делать не надо.
Week — архивы заливаются раз в неделю и хранятся 31 день.
Month — архивы заливаются раз в месяц и хранятся условно бесконечно.

Таким образом мы просто каждый день льем файлы в S3 в разные контейнеры, а там они автоматом ротируются. Мы всегда имеем 7 последних копий, 4 недельные и помесячные. Удобная схема и не очень дорогая. Стоимость хранения можете сами прикинуть по калькулятору хранилища.

Еще один вариант бэкапа — копировать базы по nfs на какой-то сервер. В общем, тут вариантов может быть очень много. Я для этого и использую такую схему — подключение директории с базами к linux серверу, а там уже возможности по работе с бэкапами безграничные. Можно на тот же Яндекс.Диск их передавать. Вот тоже статья по этому поводу — бэкап на яндекс диск. Правда там речь идет про сайт, но принципиальной разницы нет.

Заключение

Это все, что я хотел рассказать по поводу публикации файловых баз 1С в интернет. Постарался дать не только технические данные но и свои личные подробности, основанные на опыте подобных эксплуатаций. Я хоть и пытаюсь дистанцироваться от 1С, но она настолько популярна в России, что так или иначе сталкиваешься с этим продуктом. Да я и свою бухгалтерию ИП сам веду в 1С

Если захотите себе настроить что-то подобное, то обращайтесь ко мне. Я могу подобрать подходящее решение под ваш бюджет и выполнить настройку. Это будет дешевле быстрее и скорее всего лучше, чем вам настроят через франчайзи. По крайней мере то, что я видел, чаще всего было настроено так себе. Без акцента на безопасность и удобство, лишь бы работало.

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте .

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

Знания, ориентированные на практику;
Реальные ситуации и задачи;
Лучшее из международных программ.

Заключение

Подведем итог того, что мы сделали:

Настроили бэкап исходников сайтов и баз данных.
Подготовили подменный web сервер.
Перенесли на него исходники и базы данных.
Развернули базы данных из дампов.
Перенесли сертификаты сайтов.
Подготовили конфиги nginx.
Проверили работу резервного сайта и сервера.
Автоматизировали заливку свежих версий сайтов.
Настроили мониторинг резервных сайтов.

Осталось еще настроить мониторинг бэкапов и можно спать спокойно. В идеале еще и автопереключение сделать на резервный сервер, но механизм будет зависеть от конкретного случая. Если есть общий балансер, то можно переключать сервера на нем. Это удобно, но получается еще одна точка отказа (балансер), которую тоже надо резервировать. Как мне видится, лучше всего найти dns хостинг с api. Настроить ttl записи в 5-10 минут и менять автоматически ip в dns записи, если основной сервак с сайтом недоступен.

Скажу сразу, я автопереключение никогда не делал. Обычно падение прода это лютый форс-мажор, который случается раз в несколько лет. Держать постоянно наготове механизм автопереключения и тестировать его — отдельный труд. Для мелких и средних проектов это излишне. За года либо забудешь, как он работает, либо что-то сломается и в трудную минуту не отработает. Мне достаточно того, что есть живые актуальные бэкапы, и я смогу вручную переключиться на подменный сервер.

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

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

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