search

backdrop-ops / backdrop-docker

Backdrop on Docker
15 stars 9 forks source link

docker-compose does not work #20

Open izznogooood opened 6 years ago

izznogooood commented 6 years ago

image

[anders@idea ~]$ cat DockerDev/backdrop/docker-compose.yml 
backdrop:
  image: backdrop
  links:
    - db:mysql
  ports:
    - 8080:80

db:
  image: mysql
  environment:
    MYSQL_USER: backdrop
    MYSQL_PASSWORD: backdrop
    MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'
    MYSQL_DATABASE: backdrop
[anders@idea ~]$

Output:

backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET / HTTP/1.1" 500 4067 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/misc/jquery.once.js?v=1.2 HTTP/1.1" 200 1417 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/misc/normalize.css? HTTP/1.1" 200 2582 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/modules/system/css/system.css? HTTP/1.1" 200 2629 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/misc/backdrop.js?v=1.7.2 HTTP/1.1" 200 7594 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/modules/system/css/system.admin.css? HTTP/1.1" 200 2045 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/modules/system/css/system.maintenance.css? HTTP/1.1" 200 731 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/modules/system/css/system.theme.css? HTTP/1.1" 200 2892 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/themes/seven/css/seven.base.css? HTTP/1.1" 200 1128 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/themes/seven/css/responsive-tabs.css? HTTP/1.1" 200 1505 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/themes/seven/css/style.css? HTTP/1.1" 200 7668 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/misc/jquery.js?v=1.11.0 HTTP/1.1" 200 34119 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:08 +0000] "GET /core/misc/favicon.ico HTTP/1.1" 200 4058 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0" backdrop_1 | 172.17.0.1 - - [20/Jan/2018:22:36:09 +0000] "GET /core/themes/seven/js/script.js? HTTP/1.1" 200 3254 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0"

serundeputy commented 6 years ago

Hello and thanks for reporting @izznogooood !

the primary use case for this backdrop-docker image was in use in Kalabox, and now Kalabox support is depracated ... so I've not been very motivated to maintain this image.

If you are interested in using Backdrop in a containerized environment I'd encourage you to check ou t the Lando project which is the successor to Kalabox and is a very convenient way to use backdrop with containers.

thanks, ~Geoff

izznogooood commented 6 years ago

Thanks for your reply, and honesty...

I was just going to have a look at backdrop, not really looking for more work. But if I do tinker with it Ill let you know.

Thanks.

jenlampton commented 6 years ago

I'd love to get this problem resolved. If anyone is having this issue, but is also familiar with docker and wants to make us a PR -- I'd be happy to review & commit :)

freedog96150 commented 5 years ago

I have an updated docker-compose.yml file that resolves the database connectivity issue as listed here. But there is another issue that is created. When the containers come up, Backdrop fails because the proper config files are not created. Even if I drop and recreate a blank database, I cannot run either core/install.php or core/update.php and cannot recreate any of the config files. Suggestions appreciated otherwise I have to dive into the Dockerfile and the entrypoint files for the image build to see what is different on this image versus a standard install. 2019-03-04 00_59_12-error _ backdrop cms

jenlampton commented 5 years ago

Could this be a permissions issue? Maybe the system doesn't have permission to write to the config directory?

freedog96150 commented 5 years ago

I checked the local /var/www/html folder and sure enough all dirs and files set to root:root except sites/. Best to set this in the Dockerfile or entrypoint.

drupol commented 5 years ago

Same issue here, here's my docker-compose.yml file:

version: '2'
services:
  backdrop:
    image: backdrop
    links:
      - db:mysql
    ports:
      - 8080:80
    environment:
      BACKDROP_DB_HOST: mysql
      BACKDROP_DB_PASSWORD: backdrop
      BACKDROP_DB_USER: backdrop
      BACKDROP_DB_NAME: backdrop

  db:
    image: mysql
    environment:
      MYSQL_USER: backdrop
      MYSQL_PASSWORD: backdrop
      MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'
      MYSQL_DATABASE: backdrop
izznogooood commented 5 years ago

I suggest building the image locally and change the permission line in the Dockerfile.

Change the docker-compose to build . and add the Dockerfile in your compose directory, the change && chown -R www-data:www-data sites to include the dir in question.

drupol commented 5 years ago

Hi,

It doesn't work.

See the repo here: https://github.com/drupol/backdrop-docker

jenlampton commented 5 years ago

I'm confused. There's no docker-compose.yml file in this repository.

Do we need to add one? Would someone please file a PR with the necessary changes to this repo that would get this working? As a non-docker user myself, I'm also looking for co-maintainers :)

drupol commented 5 years ago

I'm more than willing to be maintainer of this :-)

jenlampton commented 5 years ago

You're the best!!!

tabroughton commented 5 years ago

Did anything happen with this? I have the same issue (I think). The log settings in the images on docker hub aren't very optimised for docker so I'm struggling to find what's going on.

in the backdrop:fpm image I get nothing, just an output stating ready for connections (which clearly isn't right) and in the backdrop:apache image I get no errors in the docker log for the container but I get this when I browse to the localhost:

Exception: The configuration directory in settings.php is specified as './files/config_a1614e81308b9e6b86be181ef0914335/active', but this directory is either empty or missing crucial files. Check that the $config_directories variable is correct in settings.php. in _backdrop_bootstrap_configuration() (line 3011 of /var/www/html/core/includes/bootstrap.inc).
freedog96150 commented 5 years ago

Did anything happen with this? I have the same issue (I think). The log settings in the images on docker hub aren't very optimised for docker so I'm struggling to find what's going on.

@tabroughton I rewrote the entrypoint.sh adding in some additional commands to handle the hashed config directory naming scheme in the settings file. That works with new Backdrop instances, but fails to bring up Backdrop when attaching existing volumes and config files. Sort of negates the purpose of using Docker with persistent volumes and databases for dev purposes. I hope that someone smarter than me figures this out as I have moved to an almost exclusive Docker dev environment for everything else. Would love to have my Backdrop dev in Docker as well.

tabroughton commented 5 years ago

After doing some testing you will get this error when any of the following is true:

  1. The files dir is not writeable by apache
  2. The container/backdrop can't connect to the database
  3. Backdrop has initialised and container has been removed and created again

The first 2 can be easily fixed though it would be good if backdrop were able to catch these and give better errors (the entrypoint.sh in this repo tries to do something similar to make up for that).

The last issue is the main one that catching us all out. I don't know backdrop or drupal7 very well but it would appear that the initialisation of the database is when the hashed directories in the files dir are created. And because a container should be stateless when we recreate the backdrop container these hashed directories $config_directories are not there.

Because the database has already initialised (or it stores a flag to say it has created these directories, or it actually stores a reference to them though I cant't find either stored from eyeballing the db) backdrop expects those directories to still exist - they don't so we get this error. It's no good just creating the directories again either with the correct hash as they need to contain the correct files.

One option to deal with this would be to use a recommended recovery procedure from the Core team. @jenlampton is there one? scenario: config_directories get deleted by accident. How to bring up backdrop with a fresh set of directories.

I imagine it would be useful if backdrop could prompt the user to reinitialise with a specific maintenance mode (rescue) or something.

Assuming this doesn't exist and a possibly a better option anyway for persistance of files created beyond initialisation is to mount volumes on host machine for /var/www/html/files. I have a working prototype, I don't have any automated tests etc. I'll share a link to it when I have pushed into a repo, I'm not confident with PR as I don't know backdrop and whether there's something I've done that would need a lot of work or is a gotcha and the changes are very big too...

drupol commented 5 years ago

@tabroughton Have you tried this ? https://github.com/drupol/backdrop-docker

tabroughton commented 5 years ago

Hi @drupol thanks for the link, I don't know composer and I'm keen to stick with simple docker container management (without using exec for example)... I don't fully follow it all and I'm sure it's similar to what I've created.

I wonder if anyone would like to try what I've done and give me some feedback https://github.com/polydigital/docker-compose-backdrop

@freedog96150 you may find it useful too.

Really appreciate any feedback from anyone.

drupol commented 5 years ago

docker-compose is actually a kind orchestrator for Docker. It will start-up the necessary docker containers that you need in order to run Docker.

Please try the image I've sent you, with 3 commands (5min max) you have an up&running Backdrop site :-)

freedog96150 commented 5 years ago

docker-compose is actually a kind orchestrator for Docker. I think he meant to imply COMPOSER. Many don't know composer or don't like it for the potential security risks. Same pushback I get with Ansible and Saltstack options in the Docker world as well.

tabroughton commented 5 years ago

docker-compose is actually a kind orchestrator for Docker. I think he meant to imply COMPOSER. Many don't know composer or don't like it for the potential security risks. Same pushback I get with Ansible and Saltstack options in the Docker world as well.

Yes that's right, I had written compose. I took a look at that repo and wasn't keen, the things I don't like are

  1. running exec commands to install within a container - it installs backdrop into a php container not ideal. I prefer a static image with versions I can depend on
  2. giving the php container access to docker.sock is a big risk to the host especially if your installing extensions, frameworks and dependencies into that container as you are
  3. credentials are being set up and will need to be changed, I'd prefer to use environment variables so I can use my favourite devops tooling
  4. I don't know composer and I don't know drush so I'd prefer to live without them for now if I can.

I can see why @drupol might have done all that but I think there's a more transparent and straight forward approach - which is the one I've taken

tabroughton commented 5 years ago

I wonder if anyone would like to try what I've done and give me some feedback https://github.com/polydigital/docker-compose-backdrop

just to be clear it's not debugging feedback I'm after it's feedback on working code. @freedog96150 what I've written should work for you. If anyone else cares to try. The reason I mention it here is because it could be a candidate to solve this issue.

drupol commented 5 years ago

I think he meant to imply COMPOSER. Many don't know composer or don't like it for the potential security risks. Same pushback I get with Ansible and Saltstack options in the Docker world as well.

Don't forget that this stack is primarily meant to be:

1. running exec commands to install within a container - it installs backdrop into a php container not ideal.  I prefer a static image with versions I can depend on

You are not forced to run composer via the container, you can run it locally. The idea behind running it into a container is that it doesn't force the user to have PHP locally installed. Having a container per service is also the way Docker is best to be used (decoupled), so we can test Backdrop with different versions of PHP and Databases.

2. giving the php container access to docker.sock is a big risk to the host especially if your installing extensions, frameworks and dependencies into that container as you are

This is a mistake that I did and I will remove it, thanks ! (edit: removed!)

3. credentials are being set up and will need to be changed, I'd prefer to use environment variables so I can use my favourite devops tooling

You can create a copy of the file taskman.yml.dist and name it taskman.yml, change anything you want in there. Regarding the .env file, it would actually be fully possible to use them, that's a good idea for Taskman actually :-)

4. I don't know composer and I don't know drush so I'd prefer to live without them for now if I can.

Fine!

I can see why @drupol might have done all that but I think there's a more transparent and straight forward approach - which is the one I've taken

I'm more than willing to receive feedback, but I have to disagree on this last point, I don't see how more transparent we can be in this case, so, feel free to develop this last point please so I can improve my repo.

Thanks

tabroughton commented 5 years ago

Hi @drupol - I'm learning loads as we go on.. I suspect we want our docker environments for different reasons. Mine, I just want a stable version of backdrop as a base to start investigating how civicrm works with it. I realise now that your's is to develop backdrop itself.

I'm more than willing to receive feedback, but I have to disagree on this last point, I don't see how more transparent we can be in this case, so, feel free to develop this last point please so I can improve my repo.

I guess the problem I have may be my lack of understanding of composer and drush etc so I don't know what it is doing when you're running scripts. With running exec commands on a container everything is hidden in the container (I know you can still run commands on it) but I like containers that are stateless and then to configure them from files I control outside the container.

Like I said I'm not creating a development environment as such...

Likely too then that the more I get interested in Backdrop the more I'll come across composer and drush and other tools I'm not familiar with yet.

drupol commented 5 years ago

Hi @drupol - I'm learning loads as we go on.. I suspect we want our docker environments for different reasons. Mine, I just want a stable version of backdrop as a base to start investigating how civicrm works with it. I realise now that your's is to develop backdrop itself.

Cool! I think it's the best setup you can get to get your hands on and develop with Backdrop.

I guess the problem I have may be my lack of understanding of composer and drush etc so I don't know what it is doing when you're running scripts. With running exec commands on a container everything is hidden in the container (I know you can still run commands on it) but I like containers that are stateless and then to configure them from files I control outside the container.

Yes and no. Let me explain if you don't mind.

I'm only using official Docker images of PHP and NGinX and I've setup the containers to expose the DOCUMENT_ROOT in the current local directory. That means that when you create a file locally, it's available in the container, and vice-versa.

When you run composer install, it will download the latest stable version of Backdrop and Drush and install them in vendor/backdrop, just like any other php library that you can install with Composer. Composer is only used to download the proper version of Backdrop and Drush, nothing else. Composer reads the file composer.json to know which version to download, you can use a fixed version or download the latest stable version. Composer is very flexible thanks to semver.

Then, the last command to run [./vendor/bin/taskman backdrop:install](https://github.com/drupol/backdrop-docker/blob/master/taskman.yml.dist#L39) will copy vendor/backdrop to build so it's at the right place for being installed through Drush. If you want to see what is doing that command, see the file taskman.yml.dist for details on what is doing the command.

PHP Taskman is a task runner where command can be defined in YAML files and you can override anything through custom files, I wrote about it here: https://not-a-number.io/2019/php-taskman-a-friendly-tasks-runner a lot of new things has been added in it since but it's a good introduction.

So, the process of setting up the files and the directories is made through Taskman, I don't rely at all on any other tool.

Then, to install Backdrop, I use Drush and it's again triggered by the backdrop:install command.

And that's it.

Like I said I'm not creating a development environment as such...

Ok, but that said, this setting could be used for production without any glitches (with Kubernetes especially).

Likely too then that the more I get interested in Backdrop the more I'll come across composer and drush and other tools I'm not familiar with yet.

Composer is not used in Backdrop for some reasons. But it's THE dependency manager for PHP. It's an amazing tool that all frameworks (and other tools) are using for managing dependencies. Drush is a command line tool to administer Drush or Backdrop. You can do everything through command line, without the need of going on a browser. It's the swiss army tool you need to have :-)

Also, and just FYI, know that it's possible to create a static image based on the result of this, but as I never did that, I don't know how to do that with Docker yet.

Good luck and choose the best tool for your setup!

freedog96150 commented 5 years ago

@tabroughton Your solution looks very self contained. I grabbed a fork and will play with it. Drush is a Drupal native CLI tool that has been ported to Backdrop. I consider this tool to be a must have as it allows the admin the ability to do almost everything on the command line that can be done from the admin web GUI and more. That is one tool I urge you to check out.

@drupol I will check out your fork as well. Thanks for all your efforts and explanations. I'll admit that for all the crazy projects I have in Docker, Backdrop has remained a challenge to configure and roll out in "Docker fashion" - that is with its own atomic image and within a reasonable size (under 80mb).

ps23Rick commented 4 years ago

@tabroughton.. just chiming in a bit late I guess.. However, I'm fairly new to Docker and just getting my feet wet, but I've got enough experience to know that my Apache, MySQL, and phpMyAdmin are working fine, but Backdrop is a fail with getting anywhere. In reading thru this thread and checking things in the backdrop container (created following the backdropcms docker page primarily), the ownership of the backdrop code is set to root as mentioned here, the settings.php is NOT setup at all for connecting to the database and lord knows what else. I just get the offending complaint when I try to run it as mentioned at the beginning of the thread.

Anyway, I'm just looking to use Backdrop and move on with my development tasks.. I will give some feedback on your above referenced repo. Thanks all!

ps23Rick commented 4 years ago

ok..@tabroughton.. I made a few minor mods mostly revolving around fixing permissions/ownership of a few more directories (e.g. core, files-core, and a few others).

Unfortunately I'm still getting the complaint below

Exception: The configuration directory in settings.php is specified as './files/config_d7cd2499e2d3eab628be27fea313d350/active', but this directory is either empty or missing crucial files. Check that the $config_directories variable is correct in settings.php. in _backdrop_bootstrap_configuration() (line 3020 of /var/www/html/core/includes/bootstrap.inc).

I'm a bit stumped on how to proceed unfortunately as Ive yet to see how this thing typically starts up. Thoughts?? I've verified that the MariaDB database is up, the backdrop database is created. Unfortunately I wasn't able to get phpMyAdmin to work for some reason. It complains with mysqli::real_connect(): (HY000/2002): No such file or directory even though I can get in with a native OS X admin tool -- I'm not too bothered at this point with figuring that one out. I'd really like to see Backdrop working.. Any thoughts/suggestions would be greatly appreciated!!

tabroughton commented 4 years ago

ok..@tabroughton.. I made a few minor mods mostly revolving around fixing permissions/ownership of a few more directories (e.g. core, files-core, and a few others).

Unfortunately I'm still getting the complaint below

Exception: The configuration directory in settings.php is specified as './files/config_d7cd2499e2d3eab628be27fea313d350/active', but this directory is either empty or missing crucial files. Check that the $config_directories variable is correct in settings.php. in _backdrop_bootstrap_configuration() (line 3020 of /var/www/html/core/includes/bootstrap.inc).

I'm a bit stumped on how to proceed unfortunately as Ive yet to see how this thing typically starts up. Thoughts?? I've verified that the MariaDB database is up, the backdrop database is created. Unfortunately I wasn't able to get phpMyAdmin to work for some reason. It complains with mysqli::real_connect(): (HY000/2002): No such file or directory even though I can get in with a native OS X admin tool -- I'm not too bothered at this point with figuring that one out. I'd really like to see Backdrop working.. Any thoughts/suggestions would be greatly appreciated!!

HI @ps23Rick I spent a few months evaluating backdrop and civicrm for project but I haven't done much with it since. here's a link to my repo, I did quite a bit of work but I'm afraid I can't really help you much to get it going. If you know docker then you should be ok https://github.com/polydigital/backdrop-civicrm-docker

ps23Rick commented 4 years ago

Thanks.. I was able to get things going just now.. The changes I made are outlined below:

I changed "ARG BACKDROP_VERSION=1.15.1" in Dockerfile just to get the latest version.

In docker-compose.yml I made the following tweaks.. The big one for me is NOT using localhost for the hostname as MySQL/MariaDB don't seem to like using that but prefer 127.0.0.1 instead (those changes are in my ".env" file. One thing I did was get rid of the default network lines at the very bottom of the file -- no need to create the "web" network as outlined in the instructions. I instead use the links feature in the file and well.. below is my adjusted file for you or anyone else's reference.. I added some dependencies and a few other odds-n-ends that frankly probably have no impact on the issue.. YMMV

`version: '3'

services: backdrop: build: . image: backdrop:apache container_name: backdrop restart: unless-stopped links:

My .env looks like : BACKDROP_DB_HOST=127.0.0.1 BACKDROP_DB_NAME=backdrop BACKDROP_DB_PORT=3306 BACKDROP_DB_ROOT_PASSWORD=super_secret BACKDROP_DB_USER=backdrop BACKDROP_DB_USER_PASSWORD=backdrop BACKDROP_PORT=80 BACKDROP_PHPMYADMIN_PORT=8080

My docker-entrypoint.sh looks like the following: `

!/bin/bash

cp /var/www/html/files-core/.htaccess /var/www/html/files/ chown -R www-data:www-data /var/www/html/files/ chmod -R 770 /var/www/html/files/ chown -R www-data:www-data /var/www/html/files-core/ chmod -R 770 /var/www/html/files-core/ chown -R www-data:www-data /var/www/html/modules/ chmod -R 770 /var/www/html/modules/ chown -R www-data:www-data /var/www/html/layouts/ chmod -R 770 /var/www/html/layouts/ chown -R www-data:www-data /var/www/html/themes/ chmod -R 770 /var/www/html/themes/ chown -R www-data:www-data /var/www/html/sites/ chmod -R 770 /var/www/html/sites/ chown -R www-data:www-data /var/www/html/core/ chown -R www-data:www-data /var/www/html/*.php

apache2-foreground`

ps23Rick commented 4 years ago

Hmm.. Ok. I tried reinstalling from scratch -- I deleted the containers and images and rebuilt using my updated files.. Unfortunately it doesn't work anymore.. Go figure. My phpMyAdmin can talk to the database, but not the backdrop container for some odd reason. I installed telnet to try talking to the MariaDB instance and this is what I get :

root@b53664645200:/var/www/html# telnet 127.0.0.1 3306 Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused root@b53664645200:/var/www/html#

I guess I am missing something with this shared networking stuff.. I see no reason why one container can talk to the db but not the other. Any ideas?

freedog96150 commented 4 years ago

Can you ping all other containers in the network from each other? Seems a bit tedious, but always a great first step. Run a container interactively (docker run -it) and ping other containers. You should be able to use container names instead of messing with IP's. If you can't ping each container, then there is possibly a network issue. Generally containers that are created in a single docker-compose by default all are members of the same network. You can explicitly assign then to the same network. If you CAN ping each container from the others, then you can look at ports as the next culprit. Is your ENV variable for your BACKDROP_DB_PORT passing or loading? Use standard net tools if available like netstat to snoop this data.

These are all just simple tips and if they have been tried, hopefully no offense is taken. None was intended and no assumption of skills have been made outside of just helping to brainstorm this issue.

ps23Rick commented 4 years ago

@freedog96150.. You're the man! I didn't know I could ping/telnet to other containers using their name.. Doh! I learned something new.. Apparently this works and I'll have to adjust my environment settings to specify the container names in the environment variables directly -- I'm assume that this will work?? If the command line works this way I'll assume the environment variables will behave equivalently.. 

root@b53664645200:/var/www/html# telnet mariadb-127.0.0.1 3306
Trying 192.168.240.2...
Connected to mariadb-127.0.0.1.
Escape character is '^]'.
p
5.5.5-10.4.12-MariaDB-1:10.4.12+maria~bionic$z_MBDls���{4.'yPd$&0^imysql_native_password^]
telnet> close
Connection closed.
root@b53664645200:/var/www/html# telnet 127.0.0.1 3306
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

Interesting that using the container name works fine but the loopback adapter doesn't but it did yesterday.. Oh well.. live and learn!! Time to move forward!!

ps23Rick commented 4 years ago

Ok. all is good now.. I'm including my updated docker-compose.yml file below. I was able to delete this once completely -- I deleted the networks (using "docker network prune"), deleted the images (docker rmi ...) and whatnot and rebuilt and the resulting image worked great without tweaking at all. Using this, there's no need to issue the "docker network create web"..

Here's the offending docker-compose.yml:

version: '3'

# edit template.env and save as .env before running docker-compose

services:
  backdrop:
    build: .
    image: backdrop:apache
    container_name: backdrop
    restart: unless-stopped
    links:
      - "backdrop-db:database"
    ports:
      - ${BACKDROP_PORT}:80
    volumes:
      - ../srv/www/backdrop/html/files:/var/www/html/files
      - ../srv/www/backdrop/html/sites:/var/www/html/sites
      - ../srv/www/backdrop/html/layouts:/var/www/html/layouts
      - ../srv/www/backdrop/html/modules:/var/www/html/modules
      - ../srv/www/backdrop/html/themes:/var/www/html/themes
    environment:
      BACKDROP_DB_HOST    : mariadb-${BACKDROP_DB_HOST}
      BACKDROP_DB_PORT    : "${BACKDROP_DB_PORT}"
      BACKDROP_DB_NAME    : "${BACKDROP_DB_NAME}"
      BACKDROP_DB_USER    : "${BACKDROP_DB_USER}"
      BACKDROP_DB_PASSWORD: "${BACKDROP_DB_USER_PASSWORD}"
    depends_on:
      - backdrop-db

  pma:
    image: phpmyadmin/phpmyadmin:latest
    container_name: backdrop_pma
    links:
      - "backdrop-db:database"
    environment:
      PMA_HOST           : mariadb-${BACKDROP_DB_HOST}
      PMA_PORT           : "${BACKDROP_DB_PORT}"
      MYSQL_ROOT_PASSWORD: "${BACKDROP_DB_ROOT_PASSWORD}"
    ports:
      - ${BACKDROP_PHPMYADMIN_PORT}:80
    depends_on:
      - backdrop-db

  backdrop-db:
    image: mariadb:latest
    container_name: mariadb-${BACKDROP_DB_HOST}
    ports:
      - ${BACKDROP_DB_PORT}:3306
    volumes:
      - ../srv/data/backdrop-db:/var/lib/mysql
      - ./custom-mysql.conf:/etc/mysql/conf.d/custom.cnf
    environment:
      MYSQL_DATABASE     : "${BACKDROP_DB_NAME}"
      MYSQL_ROOT_PASSWORD: "${BACKDROP_DB_ROOT_PASSWORD}"
      MYSQL_USER         : "${BACKDROP_DB_USER}"
      MYSQL_PASSWORD     : "${BACKDROP_DB_USER_PASSWORD}"
freedog96150 commented 4 years ago

@ps23Rick My big question for you is can you now down all your containers and bring them back up with existing volumes, etc in place? I abandoned my efforts to containerize Backdrop because I could always get the initial/new build up and running, but subsequent rebuilds always met with failure.

gardner commented 2 years ago

I just spent 4 hours trying to get backdrop working in docker. Then I found this thread.