I have an existing docker container with the name foo_db_1.
The docker-compose file is located in the foo directory.
The container contains a huge DB.
I want to rename the directory from foo to bar
So I stopped the running container and renamed the directory and the container name
mv foo bar
docker rename foo_db_1 bar_db_1
Now when I try to start the container again I get a Conflict error:
docker-compose up -d
ERROR: for bar_db_1 Cannot create container for service db: Conflict. The container name "/bar_db_1" is already in use by container "4a9204e8031d72327be283967d2b9ec3268450140f00254eb2fc51ba8af0eb58". You have to remove (or rename) that container to be able to reuse that name.
When I rename the container, then a completely new container is created and I have to import all DB data again to that container.
When I remove the container, then I will loose the DB data and also have to import all db data again.
When I run docker inspect bar_db_1 I can see, that there are several entries pointing to the foo directory.
So how can I move an existing docker setup to another directory without loosing my existing data?
My docker-compose.yml looks like this:
version: "3.8"
volumes:
db:
services:
db:
image: mariadb:10.4
environment:
MYSQL_DATABASE: 'app'
MYSQL_USER: 'dbuser'
MYSQL_PASSWORD: '1234567890'
MYSQL_ROOT_PASSWORD: '1234567890'
volumes:
- db:/var/lib/mysql
- ./db-dumps:/var/db-dumps
command: ['mysqld', '--character-set-server=utf8mb4', '--collation-server=utf8mb4_unicode_ci']
ports:
- "3306:3306"
Related
I created docker-compose yaml file to run a docker image after it has been pulled locally and this yaml file contain another services (mysql and phpmyadmin) so when I run a command docker-composer up -d I found a conflict in creating a container as it been used by another container with the same name and I expected to show me that the container is already run and up to date, I know that the container must be removed or renamed before creating a new one but I aiming to get the newer version of image and check if mysql and phpmyadmin services is up or not if up gives me those container is up to date and if not create it as another environment bellow.
docker-compose.yml
version: '3.3'
services:
app-prod:
image: prod:1.0
container_name: app-prod
ports:
- "81:80"
links:
- db-prod
depends_on:
- db-prod
- phpmyadmin-prod
db-prod:
image: mysql:8
container_name: db-prod
environment:
- MYSQL_ROOT_PASSWORD=secret
- MYSQL_DATABASE=laravel
- MYSQL_USER=user
- MYSQL_PASSWORD=secret
volumes:
- db-prod:/var/lib/mysql
phpmyadmin-prod:
image: phpmyadmin/phpmyadmin:5.0.1
restart: always
environment:
PMA_HOST: db-prod
container_name: phpmyadmin-prod
ports:
- "5001:80"
volumes:
db-prod:
Error
Creating phpmyadmin-prod ... error
Creating db-prod ...
ERROR: for phpmyadmin-prod Cannot create container for service phpmyadmin: Conflict. The container name "/phpmyadmin-prod" is already in use by container "5a52b27b64f7302bccb1c3a0eaeca8a33b3dfee5f1a279f6a809695Creating db-prod ... error
ERROR: for db-prod Cannot create container for service db: Conflict. The container name "/db-prod" is already in use by container "5d01c21efafa757008d1b4dbcc8d09b4341ac1457a0ca526ee57873cd028cf2b". You have to remove (or rename) that container to be able to reuse that name.
ERROR: for phpmyadmin Cannot create container for service phpmyadmin: Conflict. The container name "/phpmyadmin-prod" is already in use by container "5a52b27b64f7302bccb1c3a0eaeca8a33b3dfee5f1a279f6a809695f482500a9". You have to remove (or rename) that container to be able to reuse that name.
ERROR: for db Cannot create container for service db: Conflict. The container name "/db-prod" is already in use by container "5d01c21efafa757008d1b4dbcc8d09b4341ac1457a0ca526ee57873cd028cf2b". You have to remove (or rename) that container to be able to reuse that name.
ERROR: Encountered errors while bringing up the project.
Error: No such container: app-prod
Error: No such container: app-prod
While using another docker-compose file for test environment I got this which I expected
db-stage is up-to-date
phpmyadmin-stage is up-to-date
Creating app-stage ... done
docker-compose run command will create new containers. But in your case, 2 of them are already running, hence, you can use
docker-compose up -d
That specific error is easy to fix. You're trying to manually specify container_name: for every container, but the error message says you have existing containers with those same names already. Left to its own, Compose will assign non-conflicting names, and you can almost always just delete container_name: from the Compose file.
version: '3.8'
services:
app:
image: prod:1.0
ports:
- "81:80"
depends_on: [db, phpmyadmin]
# no container_name: or links:
db: { ... }
phpmyadmin: { ... }
The other obvious point of conflict for running the same Compose file in multiple places is the ports:; only one container or host process can listen on a given (first) port number. If you're trying to run the same Compose file multiple times on the same system you might need some way to replace the port numbers. This could be a place where using multiple Compose files fits in well: define a base docker-compose.yml that defines the services but not any of the ports, and an override file that assigns specific host ports.
As I have several docker-compose files and I run this command docker-composer -f <compose_file_path> -p <project_name> -d up and then I try to run docker-composer up -d in the same location without specify the project name -p <project_name> which gives me the conflict of the container as this make the compose-file up with a different project name and with the same container name.
I stumbled across a problem with docker volumes while starting docker containers with a docker compose file (MariaDB, RabbitMQ, Maven). I start them simply with docker-compose up -d (WITHOUT SUDO)
My volumes are definied like this:
...
volumes:
- ./production/mysql:/var/lib/mysql:z
...
Everything is working fine and the ./production directory is created (where the volumes are mapped)
But when I again try to restart the docker containers with down/up, I get following error:
error checking context: 'no permission to read from '…/production/mysql/aria_log.00000001'
When I check the mentioned file I saw that it needs root:root permission. This is because the file is generated with the root user inside the container. So I tried to use namespace as mentioned in the docs.
Anyway the error still occurs. Any ideas or references?
Thanks.
Docker Compose File:
version: '3.8'
services:
mysql:
image: mariadb:latest
restart: always
env_file:
- config.env
volumes:
- ./production/mysql:/var/lib/mysql:z
environment:
MYSQL_DATABASE: ${DATABASE_NAME}
MYSQL_USER: ${DATABASE_USER}
MYSQL_PASSWORD: ${DATABASE_PASSWORD}
MYSQL_ROOT_PASSWORD: ${DATABASE_PASSWORD}
networks:
- testnetwork
networks:
testnetwork:
The issue comes from the mapping between the host user/group IDs and the ones inside the container. One of the solutions is to use a named volume and avoid all this hassle, but you can also do the following:
Add user: ${UID}:${GID} to your service inside the docker-compose file.
Run UID=${id -u} GID=${id -g} docker-compose up. This way you make sure that the user in the container will have the same UID/GID as the user on the host and files created in the container will have proper permissions.
NOTE: Docker for Mac (using the osxfs driver) does this behind the scenes and you don't need to worry about users and groups.
Run the Docker daemon as a non-root user this can be helpfull for your purpose.
all document are here.
I have been trying to install drupal using the official image from docker hub. I created a new folder in my D directory, for my Drupal project and created a docker-compose.yml file.
Drupal with PostgreSQL
Access via "http://localhost:8080"
(or "http://$(docker-machine ip):8080" if using docker-machine)
During initial Drupal setup,
Database type: PostgreSQL
Database name: postgres
Database username: postgres
Database password: example
ADVANCED OPTIONS; Database host: postgres
version: '3.1' services:
drupal:
image: drupal:8-apache ports:
- 8080:80
volumes:
- /var/www/html/modules
- /var/www/html/profiles
- /var/www/html/themes
this takes advantage of the feature in Docker that a new anonymous
volume (which is what we're creating here) will be initialized with the
existing content of the image at the same location
- /var/www/html/sites
restart: always
postgres:
image: postgres:10
environment:
POSTGRES_PASSWORD: example
restart: always
When I ran the docker-compose up -d command in a terminal from within the folder which constrong texttained docker-compose.yml file, my drupal container and its databse were successfully installed and running and I was able to access the site from http://localhost:8080 but I couldnt find their core files in the folder. It was just docker-compose.yml file in the folder.
I then removed the whole docker container and began with a fresh installation again with by editing the volume section in the docker-compose.yml file to point to the directory and folder where I want the core files of drupal to be populated.
Example D:/My Project/Drupal Project.
Drupal with PostgreSQL
Access via "http://localhost:8080"
(or "http://$(docker-machine ip):8080" if using docker-machine)
During initial Drupal setup,
Database type: PostgreSQL
Database name: postgres
Database username: postgres
Database password: example
ADVANCED OPTIONS; Database host: postgres
version: '3.1'
services:
drupal:
image: drupal:latest
ports:
- 8080:80
volumes:
- d:\projects\drupalsite/var/www/html/modules
- d:\projects\drupalsite/var/www/html/profiles
- d:\projects\drupal/var/www/html/themes
this takes advantage of the feature in Docker that a new anonymous
volume (which is what we're creating here) will be initialized with the
existing content of the image at the same location
- d:\projects\drupalsite/var/www/html/sites
restart: always
postgres:
image: postgres:10
environment:
POSTGRES_PASSWORD: example
restart: always
When I ran the docker-compose.yml command I received the error as shown below.
Container drupalsite_postgres_1 Created 3.2s
- Container drupalsite_drupal_1 Creating 3.2s
Error response from daemon: invalid mount config for type "volume": invalid mount path: 'z:/projects/drupalsite/var/www/html/sites' mount path must be absolute
PS Z:\Projects\drupalsite>
Please help me find a solution to this.
If these directories contain your application, they probably shouldn't be in volumes: at all. Create a file named Dockerfile that initializes your custom application:
FROM drupal:8-apache
COPY modules/ /var/www/html/modules/
COPY profiles/ /var/www/html/profiles/
COPY themes/ /var/www/html/themes/
COPY sites/ /var/www/html/sites/
# EXPOSE, CMD, etc. come from the base image
Then reference this in your docker-compose.yml file:
version: '3.8'
services:
drupal:
build: . # instead of image:
ports:
- 8080:80
restart: always
# no volumes:
postgres:
image: postgres:10
environment:
POSTGRES_PASSWORD: example
restart: always
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:
If you really want to use volumes: here, there are three forms of that directive. The form you have in the question with just a path creates an anonymous volume: it causes Compose to persist that directory, initialized from what's in the image, but disconnected from your host system. With a bare name and a path, it creates a named volume, which is similar but can be explicitly managed. With two paths, it creates a bind mount, which unconditionally replaces the container content with the host-system content (there is no initialization).
version: '3.8'
services:
something:
volumes:
- /path1 # anonymous volume
- named:/path2 # named volume
- /host/path:/path3 # bind mount
volumes: # named volumes referenced in containers only
named: # usually do not need any settings
So if you do want to replace the image's contents with host directories, you need to use the bind-mount syntax. Relative paths here are interpreted relative to the location of the docker-compose.yml file.
version: '3.8'
services:
drupal:
image: drupal:8-apache
volumes:
- ./modules:/var/www/html/modules
# etc.
A final comment on named volume initialization: your file has a comment about initializing anonymous volumes. There are two major problems with this approach, though. First, the second time you start the container, the content of the volume takes precedence, and any changes in the underlying images will be ignored. Second, this setup only works for Docker named and anonymous volumes, but not Docker bind mounts, volume mounts in Kubernetes, or other types of mount. I'd generally avoid relying on this "feature".
I have an issue. I used my docker-compose file for one project. Then I copied it to another directory in order to run another containers. But whenever I do that it recreates existing containers or in case I use the down command it also destroys containers from another directory, what could be wrong?
Here is my configuration.
version: '3.5'
services:
postgres:
image: postgres
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: password
PGDATA: /data/postgres
volumes:
- postgres:/data/postgres
ports:
- "5440:5432"
networks:
- postgres
restart: unless-stopped
pgadmin:
image: dpage/pgadmin4
environment:
PGADMIN_DEFAULT_EMAIL: admin#admin.com
PGADMIN_DEFAULT_PASSWORD: rootme
volumes:
- pgadmin:/root/.pgadmin
ports:
- "8440:80"
networks:
- postgres
restart: unless-stopped
networks:
postgres:
driver: bridge
volumes:
postgres:
pgadmin:
For example when I run docker-compose up -d from another directory it recreates containers
Recreating docker_postgres_1 ... done
Recreating docker_pgadmin_1 ... done
What is the issue?
Docker Compose attaches a name prefix to everything it creates, but the default prefix is just based on the basename of the current directory. If you have a layout like
projectA
+-- docker
| \-- docker-compose.yml
projectB
\-- docker
\-- docker-compose.yml
then both docker-compose instances will think the project name is just docker (the name of the directory containing docker-compose.yml) and create container names like, for example, docker_postgres_1.
You can get around this by either renaming one of the directories, using the docker-compose -p option, or setting a COMPOSE_PROJECT_NAME environment variable. It wouldn't be unusual to see a docker-compose.yml file in the top-level directory of a project and that might help disambiguate things.
I believe that it occurs because of the containers on the previous project continue running while you try up the new project.
Try to stop the containers on the previous folder before upon the current.
I have 2 docker containers. One running tomcat and the other running mysql. I want to copy a .sql file into the already existing "docker-entrypoint-initdb.d" folder of the mysql container.
I used the following command in my Dockerfile:
COPY test.sql /docker-entrypoint-initdb.d
After both containers are started I saw that the folder "docker-entrypoint-initdb.d" was created in my tomcat container and the test.sql was copied into it.
The file isn't copied where I need it to be. test.sql wasnt copied into the mysql container.
What can I do?
docker-compose.xml:
version: "2"
services:
db:
image: mysql
environment:
- MYSQL_ALLOW_EMPTY_PASSWORD="true"
myapp:
build: ./myapp
ports:
- 8080:8080
- 3306:3306
Build your own image for the database container with a Dockerfile like this:
FROM mysql
COPY test.sql /docker-entrypoint-initdb.d
tomcat container is build via docker file, where as mysql container(db) is build via the docker image name "mysql".
You can mount the volume with current folder (host) to "/docker-entrypoint-initdb.d" inside the container.
new docker-compose.yml will look like this.
version: "2"
services:
db:
image: mysql
environment:
- MYSQL_ALLOW_EMPTY_PASSWORD="true"
volumes:
- .:/docker-entrypoint-initdb.d
myapp:
build: ./myapp
ports:
- 8080:8080
- 3306:3306
You are building tomcat container, But using Mysql image there, Thats why the file copied to tomcat container.
When containers are up you can docker cp the file manually to the desired location.
If you want to have the database available to container at startup, I suggest you use a dummy container with mounted local filesystem. Then restore the database manually in that container. Then remove the container and modify dockerfile like this:
version: "2"
services:
db:
image: mysql
environment:
- MYSQL_ALLOW_EMPTY_PASSWORD="true"
volumes:
- /my/own/datadir:/var/lib/mysql
myapp:
build: ./myapp
ports:
- 8080:8080
- 3306:3306
Another way would be creating your own image using following dockerfile:
FROM mysql
COPY test.sql /docker-entrypoint-initdb.d