MikUrrey

Это называется network aliases
Пример:

services:
  proxy:
    image: jwilder/nginx-proxy
    ports:
      - 0.0.0.0:80:80
      - 0.0.0.0:443:443
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock
      - ./certs/:/etc/nginx/certs:ro
      - ./jira-nginx.conf:/etc/nginx/vhost.d/jira.local.net
    networks:
      proxy:
        aliases:
          - "site.local.net"

Другой контейнер сможет обращаться к этому по имени контейнера (proxy) - как обычно , а также по alias - site.local.net
То есть строка c адресом и именем этого контейнера будет в файлах hosts всех остальных контейнеров стека.

вот тут почитайте как работает сеть в compose
https://docs.docker.com/compose/networking/
для вашего случая наверное стоит обратить внимание на два предложения

By default Compose sets up a single network for your app. Each container for a service joins the default network and is both reachable by other containers on that network, and discoverable by them at a hostname identical to the container name.

Instead of just using the default app network, you can specify your own networks with the top-level networks key. This lets you create more complex topologies and specify custom network drivers and options. You can also use it to connect services to externally-created networks which aren’t managed by Compose

короче, если Вы НЕ указываете networks в docker-compose, то compose использует default bridge и сам увязывает контейнеры по имени между собой.
Если указываете кастомный network (openweb-network в вашем случае) то с именами придется возиться самому

и эта ...

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

нет это не так работает. У контейнеров своя сеть openweb-network. Адрес можно посмотреть командой
docker network inspect openweb-network

Устанавливаете один мускуль в один каталог, второй - в другой. Разносите по разным портам/сокетам.

Или, не страдая костылями, просто делаете два контейнера/виртуалки.

return this.getValue(objectValues[valueArray[0]], valueArray.slice(1).join('.'), defaultV);
//                                                                                ^^^^^^

composer?

Делаете один include 'vendor/autoload.php', а остальное тянет сам композер по правилам из composer.json (psr-0, psr-4,..).

https://getcomposer.org/doc/04-schema.md#autoload

Вот пример
https://codepen.io/begprod/pen/abbaMgX

Не бездарна, просто не уделили еще достаточно времени пониманию работы приложений и реальному ООП) Но этим стоит заняться - книги есть, видеокурсы есть.
Примеры приложений можно поискать.
Что здесь нужно?
1. Точка входа (index.php), которая будет перенаправлять на реальную страницу
2. Способ сопоставления роута с реальным экшеном контроллера
3. Группа классов контроллеров
4. Группа классов моделей (сущностей)
5. Группа шаблонов (вьюх)
6. Другие группы классов (сервисы, модули и т.п.) по необходимости
Если совсем трудно без фреймворка, попробуйте влоб написать процедурный php для решения задачи, потом вычленять код в методы и классы с конкретным предназначением. Почитайте в документации знакомого Вам фреймворка раздел про жизненный цикл запроса и разберите все по полочкам. Успехов!)

Загружайте конфиг до инициализации приложения:

store.dispatch('config/loadMain').then(() => {
  new Vue({
    ...

https://play.google.com/intl/en_us/badges/