Сергей П

А для чего? У вас много таких клманд и нужно их массово превращать в ямлы? Одну-две можно и руками мгновенно оформить.
Где это вам в промышленных масштабах так надо ковертить?

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

Основное, что дает докер - это изоляцию частей вашей системы друг от друга. За счет этого гораздо проще всё настраивать.
- БД настраивается в отдельном докер-контейнере. В большинстве случаев вы используете стандартный образ и подаете ему только настройки.
- nginx настраивается в отдельном контейнере вместе с certbot'ом, который будет обновлять вам сертификат ssl.
- бэкенд поднимаетя в отдельном контейнере на стандартном порту (и порт не будет конфликтовать с другими бэкендами в других контейнерах на том же порту.
- другие какие-то бэкенды и админки будут рядом сидеть в отдельны контейнерах и не будут конфликтовать друг с другом версиями библиотек. интерпретаторов и чего угодно
- компиляция и сборка тоже делаются в контейнере, который не запускается в прод, но обеспечивает иоляцию этого процесса так, что другие разработчики легко приступят к работе без долгой и уникальной настройки своего рабочего места.

Весь набор нужных контейнеров для проекта конфигурируется docker-compose файлом и в большинстве случаев при правильной настойке чтобы поднять дев-стенд или продакшн вам достаточно будет склонировать репу на комп и скомандывать docker-compose up.

Про слои и переиспольование почитайте в документации к докеру. Докер-образы наследуются накладывая свои изменения слоями. Это экономит место на диске и упрощает всю систему минимизируя число возможных состояний.
Вся файловая система контейнера не примонтированная извне будет стёрта и забыта при перезапуске контейнера. Так можно быть уверенным, что ваш бэкенд не оставляет лишних неучтенных побочных эффектив. Это упрошает отладку и поиск проблем.

Для пошагового гайда или даже более-менее полезного ответа вы не предоставили почти никаких данных.
Смысл докера в изоляции отдельных сервисов и программ в отдельных контейнерах так, чтобы они не конфликтовали за ресурсы (порты, файловую систему, зависимости от библиотек) и никак не мешали друг другу.
LAMP - это линукс, апач, mysql, php. Если всё делать в докере, то у вас будет отдельный контейнер для БД. Его можно без изменений брать с докерхаба стандартный.
Не разбираюсь в этих ваших ПХП, но если бы бэк у меня был на питоне, я бы использовал nginx и тоже подняол бы его в отдельном контейнере. ьно бэкенд тоже поднимал бы в отдельном контейнере. Всё это оркестрировал бы докер-компоцзом.
Вам следет пойти на гитхаб и поискать пример LAMPовых проектов, с компоуз-файлом. Какие-нибудь популярные, простые и звездатые. Там и подсмотрите как организовать всё.

Просто брать всё что у вас на ВПС и пихать в один контейнер смысла нет.

Основное отличие микросервисов от монолита в том, что они более автономны и изолированны друг от друга. Общаться между собой они, кстати, могут не только по http, чаще это происходит через очереди RMQ или кафку какую-нибудь.
Если несколько микросервисов у вас будут хранить данные в одной БД или вообще в одной таблице, то это несколько ухудгает изоляцию и ваша микросервисаня архитектура снова начинает пахнуть монолитом, только затейливым таким монолитом, поскольку, возможно, вы на следующих этапах захотите вынести общий код из микросервисов в какие-то библиотеки, начнете импортировать одни и те же модели разными "микросервисами". И получите в итоге тот же монолит со всеми его недостатками, а достоинства микросервисной архитектуры потеряете, приобретя при этом её недостатки.

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

Для разработки и отладки вы обычно изолированы в своём микросервисе, вам может быть достаточно для девелоперских нужд докер-компоуза, который поднимет вам БД, nginx, очереди и что вам там еще надо для нужд локальной отладки и тестирования.

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

хорошая идея всё делать в докере. Во многом упрощает жизнь при развёртывании.

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

Просто добавить в папку проекта Dockerfile и там прописать все?

Забавно, но... ДА!