Кирилл Маслов

Нет в микротиках management vlan
По факту сервисы работают на всех интерфейсах где есть ip.
Доступ к ним можно ограничить в настройках сервиса + навесив ACL на INPUT цепочку и все интерфейсы окромя того который выделен для управления.

Так это не downgrade, это upgrade пакетов на версию новее, который вполне стандартен.

Решается через отключение update для соответствующих пакетов:

echo "postgresql-10 hold" | sudo dpkg --set-selections
echo "postgresql-client-10 hold" | sudo dpkg --set-selections
echo "postgresql-client-common hold" | sudo dpkg --set-selections
echo "postgresql-common hold" | sudo dpkg --set-selections
echo "postgresql-doc-10 hold" | sudo dpkg --set-selections
echo "postgresql-server-dev-10 hold" | sudo dpkg --set-selections

sudo apt-mark hold postgresql-10
sudo apt-mark hold postgresql-client-10
sudo apt-mark hold postgresql-client-common
sudo apt-mark hold postgresql-common
sudo apt-mark hold postgresql-doc-10
sudo apt-mark hold postgresql-server-dev-10

Скачайте deb-пакет фронта и установите через dpkg
https://repo.zabbix.com/zabbix/4.0/ubuntu/pool/mai...

Правильно будет поставить certbot котырый настроит nginx или apache для нужных доменов и будет сам продлевать сертификат.

Оказалось все просто)

xrandr --addmode VIRTUAL1 1920x1080
xrandr --output VIRTUAL1 --mode 1920x1080
x11vnc -rfbport 25901 -clip 1920x1080+1920+0 -forever

А дальше уже на второй машине ставим VNC клиент и подключаемся.
По аналогии команд выше можно еще один дисплей добавить.

Правильнее ставить routing mark и на её основании принимать решение о маршрутизации

Этих правил может быть несколько, по вашему вкусу
/ip firewall mangle
add action=mark-routing chain=prerouting dst-port=80 in-interface=bridge-lan new-routing-mark=to-gre passthrough=no protocol=tcp

Строчка маршрута, при падении канала пакеты пойдут в шлюз по умолчанию
/ip route
add check-gateway=ping distance=1 gateway=10.10.10.1 routing-mark=to-gre

10.10.10.1 - адрес gre-интерфейса удалённого сервера

вместо "&&" используй ";" Люк !!
а вообще - почитать что такое &&

location / {
        rewrite ^/(.*)$ /1.0/index.php last;
    }

Saboteur неплохо ответил(что не отменяет того что все остальные ответившие тоже правы)
Девопс - это практики. Это не набор инструментов( инструменты используются на определенных этапах, реализация которых необходима для приближения к идеалу), однако определенные необходимые инструменты опять же есть.
Про девопс можно прочитать очень много информации, но я, как админ (win-админ :D) вижу ситуацию для вас, как и любого, с опсовой основой, примерно так:

1. Жирным вы выделили вопросы который для вас вот конкретно сейчас не играют ни малейшей роли. Дмитрий Шицков и Saboteur написали почему: зависит от проекта.
   
2. Завет любого ops-а: автоматизируй всё что можно
   Если выбор между configuration management (chef, ansible, puppet и тд) и скриптами - то лучше первое. Хотя и тут можно поспорить, у меня в проекте chef-ом автоматизированное не очень-то используется на последнем этапе доставки в прод, поскольку мы все равно запечатываем машину и запускаем в AWS с asg без пост-конфигурации. Тут можно до посинения спорить хорошо это или нет, но скрипты в идеальном мире проигрывают DSL
   
3. Вы пишете код для автоматизации
   Вам понадобится git (который тянет за собой git-хостинг: bitbucket, github, gitlab и тп.) и навыки правильной работы с гитом. Для отслеживания и планирования изменений - понадобится какой-нибудь таск трекер (jira, таск трекер встроенный в gitlab, что-то другое).
   
4. Инфраструктура как код
   Автоматизируй всё означает автоматизацию развертывания инфраструктуры
   Здесь уже вступают в силу особенности вашего окружения - в облаках вы скорее всего захочете использовать terraform или, например, CloudFormation в AWS - встроенное средство оркестрации, или же будете сразу все запускать в контейнерах - docker , kubernetes используя соответствующие инструменты.
   
5. Мониторинг
   Без правильного и подходящего вашему продукту мониторинга(+логирования) жить нельзя. И это было еще до DevOps тренда - это классика администрирования. Здесь ничего не посоветую, с Zabbix-ом сам не ужился, переехал на influx и прилегающие (TICK stack). Для логирования - graylog, ELK. В некоторых частях используется prometheus который в том числе и для кубера удобен. В общем - с чем подружитесь.
   

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

Для примерного осознания всего цикла можно посмотреть на (картинка относительно рандомная,таких много, два года назад я ориентировался по другой, с более подходящим мне списком инструментов, но найти не могу =( )


P.S. Еще раз хочу отметить что описанное выше основано на личном опыте и это - движение в devops со стороны ops. Есть те, кто сразу пытаются строить все по девопсу параллельно обучаясь опсовой части и девелоперской( видел таких, не у всех получалось ). Есть те, кто двигается в девопс со стороны Dev. Все будут иметь разные мнения что важно для того, чтобы начать

iptables -A INPUT -p tcp -m tcp -m multiport ! --dports 25565 -j DROP

перед тем как добавите это правило, вспомните что вы подключены к серверу по ssh через 22 порт.
Сайт возможно работает на 80/443.
А фтп для доступа к сайту на 21, если он есть.