Макс

Одно из двух:
- либо вы будете ~месяц вырисовывать на поэтажном плане мельчайшие подробности для точного рассчёта;
- либо нарисуете план быстро, но рассчитанную длину надо будет умножать на 2, а может быть и на 3.
https://ru.wikipedia.org/wiki/Парадокс_береговой_линии

Поэтому обычно монтажники не отмеряют и не отрезают заранее, а тянут кабель прямо из бухты; сколько получится - столько и отрежут (если опытные и ответственные, то ещё запас оставят несколько метров, ориентируясь по ситуации на месте).

Для этой задачи - systemd достаточно
Docker - для разворачивания в изолированной среде. Для независимости, переносимости.

UNION
www.sql.ru/docs/sql/u_sql/ch14.shtml

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

5-7 тысяч посетителей в день почти ни о чём не говорят. Есть большая разница между тем, что каждый посетителей просто скачает за десять секунд статическую mp3'шку или если каждый из них в течении часа будет удерживать соединение с сервисом, на лету кодирующем и сами media-данные и rtsp-поток для них. В первом случае можно на самом дешманском виртуальном хостинге запуститься, а во втором может и VDS'а не хватить.

update table set btc=123 where id=1

Разделите понятия DEV контейнер и PROD контейнер.
DEV образ не содержит в себе код вашего проекта, он содержит только окружение, а код маунтится через volume. Инженер делает правки у себя лакально, sftp не требуется.
PROD контейнер содержит в себе конкретную версию код со всем и зависимостями, он только запускается для работы в связке с DEV контейнерами.

Например у вас есть сервисы: sa, sb, sc.
В docker-compose.yml вы прописываете 6 сервисов: sa_dev, sa_prod, sb_dev, sb_prod, sc_dev, sc_prod.
Пары *_dev и *_prod живут на одинаковых ip с одинаковыми DNS алиасами, это нужно для того, что бы обеспечить жесткую связь между вашими сервисами и не перехреначивать половину docker-compose.yml

Например вы хотите сделать правки на sb, но sa и sc используются sb. Вы поднимаете:
sa_prod, sb_dev, sc_prod.
Делаете свои правки, проверяете. Когда все ок - коммитите правки и собираете новый образ sb_prod, пушите его в регистр и обновляете версию в docker-compose.yml

Сервер печати
https://habr.com/post/257297/

Такие задачи я решаю с помощью ACL. Вот пример скрипта, который устанавливает нужные права на нужные директории (пользователи, естественно, должны уже существовать):

#/bin/sh
setfacl -R -b /folder/subfolder
setfacl -R -m u:www-data:rwx /folder/subfolder
setfacl -R -d -m u:www-data:rwx /folder/subfolder
getfacl /folder/subfolder

PS Если я правильно понял вопрос, конечно.

Для простого парсинга логов лучше всего вызывать не bash, а пользовать awk/gawk.
https://codeby.net/analiz-log-fajlov-apache/
https://proft.me/2011/05/8/awk-parsing-fajlov-po-s...
Ну и в гугле по словам awk gawk
Ну и талмуд от айбимэ https://www.ibm.com/developerworks/ru/library/l-aw...

Чтобы начать чем-то управлять, придётся сначала побыть управляемым. Устраиваешься в проект программистом/админом/консультантом, проходишь через жизненный цикл проекта наблюдая как что работает и какие проблемы возникают. На следующем проекте (или этом же, если он "вечный") начинаешь себя проявлять: показываешь умение и готовность решать вопросы, находить решения, разговаривать с людьми - коллегами, руководством, заказчиками, умение убеждать и вдохновлять, умение предугадывать желания заказчика и будущие проблемы и т.д. и т.п. Естественным образом рано или поздно начнёшь "тащить" проекты, а после этого менеджером назначат даже если сопротивляться будешь.

Ответ на похожий вопрос.

Я бы не стал заморачиваться с поиском лучшего решения на пустом месте, если бы лучшая бд существовала, остальные бы умерли в неизвестности. В вашем случае я бы использовал MySQL, как минимум на начальном этапе, и вот почему:
1) Это бесплатно
2) Мускуль - хороший добротный середнячек своего класса, то есть он умеет почти все и при этом сильно не проседает по производительности.
3) На него ОГРОМНОЕ количество доков и юзеркейсов, а так же туториалов и советов по оптимизации в конкретную задачу.
4) При смене бд(если таковая понадобится) вам, скорее всего, придется только поменять драйвер бд(при условии грамотной архитектуры) и аккуратно перенести дамп базы.
5) Про MSSQL - до недавнего времени в ней не было нативной поддержки UTF-8, вместо нее была(и есть еще вроде) своя UCS, которая мультибайт, но какой-то свой(как всегда у мс), в свое время в угоду "скорости" ставили сервак с мсскулем, в итоге практически никакого прироста не получили, зато получили гемор с переводом кодировок.
6) Если проект реально нуждается в разрывном бд на пределе современных возможностей - смотрите в сторону инмемори бд, например тарантул или что-то носкюельное, типа редис и иже с ним.

Нормальных знаний по программированию ВУЗы тоже не дают.

1. Поднять DHCP, прописав выдачу уже имеющихся IP с привязкой к MAC.
2. Поменять настройки на клиентах, переключив со статических адресов на DHCP.
3. Разработать новый план адресации, подготовить новые конфиги DHCP и DNS.
4. В нерабочее время перенастроить DHCP-сервер на выдачу IP по новому плану, поменять настройки DNS.
5. Заменить адреса там, где они должны быть статическими (серверы, шлюзы, принтеры).
6. По необходимости перезагрузить клиенты или перезапросить на них IP.