Вадим

Это считается не docker-way (правильнее в отдельном контейнере запустить отдельный обработчик очереди), но можно так:

одна команда & другая команда

Можно также сделать скрипт, который всё как надо запустит, и использовать его в качестве cmd. Можно также внедрить в контейнер микросистему управления сервисами типа runit.

Почему считается, что плохо так делать? Если php-fpm упадёт, то весь контейнер упадёт и может перезапуститься автоматом. А если упадёт второй сервис, то контейнер будет работать как ни в чём не бывало.

Взять и прочитать правила :) Прямого списка там может и не быть. Более того, я бы не стал там его держать, например. Есть такая штука - ipset, предназначен для хранения списков адресов, портов etc. И он очень часто работает в паре с iptables. Если используется ipset в самом правиле iptables никакого списка адресов не будет.

Вот например, как я блокирую RFC1918-адреса на входе с внешнего интерфейса (то есть там, где их теоретически быть не должно):
/etc/sysconfig/ipset

# RFC1918 networks
create rfc1918 hash:net family inet hashsize 1024 maxelem 65536 
add rfc1918 10.0.0.0/8
add rfc1918 172.16.0.0/12
add rfc1918 192.168.0.0/16

/etc/sysconfig/iptables
*mangle
# Mark packets, which BEFORE NAT have RFC1918-compliant addresses
-A PREROUTING -i eth1 -m set --match-set rfc1918 src -j MARK --set-mark 1
*filter
# Drop packets, which marked to drop in mangle table
-A FORWARD -m mark --mark 1 -j DROP

Например, моя рабочая Убунта занимает 20 Гб диска.
100 Гб - за глаза.
Стоит поискать тот LiveCD, который на вашем ноуте таки запустится без установки, чтобы посмотреть, насколько поддерживается железо.
В ноуте могут быть Win-only железки, на которых производитель сэкономил, вынеся логику в виндовский драйвер и не предлагая никакого другого. Обычно это модуль WiFi, тачпад (могут не поддерживаться некоторые возможности), сканер отпечатка и подобный второстепенный обвес.
Но самой системе загрузиться это барахло никак не мешает.
Может, впрочем, спотыкаться система энергосбережения, вешая систему в произвольный момент. Тут придется покопаться в BIOS/UEFI, отталкиваясь от того, что находится в Гугле по сочетанию "{ваш процессор}+Linux+freeze".

1. принято. Если кто-то станет шикать на вас за это — это их проблемы, а у нас свободные нравы!
2. правильно.

С монтированием – по-разному. Как удобнее. Варианты:

• в проекте папка /docker под ней в подпапке /docker/nginx – конфиги nginx, которые биндятся в контейнер по одному, или всей подпапкой. Удобно, если захочется по-живому редактить конфиги;
  
• в контейнер при его билде, инструкциями в его Dockerfile, копируются файлы из папки;
  
• прилетает уже готовый-собранный образ, из которого поднимается рабочий контейнер, не запариваясь расположением конфигов и какими-то настройками.
  

Логи направляются в Stdout контейнера и хранятся Docker'ом. Посмотреть хвост: docker logs --tail 50 имя_контейнера

Не надо так делать. Graphql это только gateway. Использовать его как интерфейс к базе данных, даже через бизнес-логику это такое себе решение. Хотя можно, конечно, кто же спорит. Федерации это удобно, но на масштабе проще застрелиться, чем заниматься этим. Сам aplollo ничего не сделает за вас - это фреймворк, не больше) ну и большое комьюнити с готовыми модулями

ORM его использует. А использовать его самому в Django проекте - это глупость, аннулирующая всю пользу от применения Django.

Ценятся знания и опыт. И только.

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

location = /myfile.json {
  add_header 'Access-Control-Allow-Origin' '*';
}

Иметь ввиду, что объявление add_header в блоке location перекрывает заголовки, объявленные в блоке server, потому при необходимости продублировать их.

aws secrets manager или aws parameter store

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

А мычит он не про сам шелл, а про используемый в нем скриптовый язык.
И ответ получается очень простой - для некоторых задач Bash scripting language тупо подходит лучше. Не говоря уже про интеграцию скриптового языка баш в командную оболочку баш, какой никогда не добиться с помощью "обёрток".

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

Так что да - или легаси, или тупо адекватность задаче.

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

Насколько я понимаю раньше шеллы использовались в качестве примитивных высокоуровневых языков. Сейчас у нас есть Perl, Python, nodejs, php...

Ну давайте вместо рабочего стола пользователю дадим сразу Visual Studio, ведь какая разница как программу запускать - иконкой на рабочем столе, или форкать из высокоуровневого языка?

shell - это оболочка операционной системы. То, что кроме графической есть еще и command line interface - это совершенно нормально и адекватно. И шелл позволяет пользователю и администратору работать в операционной системе гораздо удобнее, чем через язык программирования.

То, что sh/bash и другие, настолько развиты что сами по себе являются неплохими языками программирования - это просто следствие того, что командый интерфейс и создавался тогда, когда каждый пользователь был немного программистом, и следствие того, что cmd line удобен для автоматизации просто по своей архитектуре.
Поэтому Powershell, bash/zsh/ksh будут продолжать развиваться.

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