I have ran into this problem when opening the project in container.
Setting up container for folder or workspace: c:\Work\playground\moodle\lms_administrace
Run: docker-compose -f c:\Work\playground\moodle\lms_administrace\docker\docker-compose-dev.yml config --services
app
redis
db
phpmyadmin
Run: docker-compose --project-name docker -f c:\Work\playground\moodle\lms_administrace\docker\docker-compose-dev.yml up -d --build
Creating volume "docker_mysql_data_volume" with default driver
Pulling app (nodejs:)...
ERROR: The image for the service you're trying to recreate has been removed. If you continue, volume data could be lost. Consider backing up your data before continuing.
Continue with the new image? [yN]
The problem is that I cannot press y or N. I know why I'm having this problem - because I have used that docker compose file before and containers and volumes were created with the directory prefix (docker).
There's a way how to change the compose project name through .env file, but it does not work (I put the file in the root directory, in the directory where compose file is, and in the .devcontainer folder). And also there is -p parameter, but the MS GitHub page does not provide any information.
I can probably fix it by renaming everything, but this may be a serious issue since you can't continue in the process ...
Did anybody experienced similar problem and fixed that?
Thanks,
Karel
You probably mistyped service docker image name in docker-compose.yml.
You are trying to pull nodejs image instead of node
Also, there is could be same error with case postgresql and postgres.
I had the same problem,My problem is using the wrong mirror name.
Related
JVMStabilityInspector.java:196 - Exiting due to error while processing commit log during initialization.
org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException: \
Could not read commit log descriptor in file /opt/cassandra/data/commitlog/CommitLog-7-1676434400779.log
I ran the Cassandra container in Docker, and the above error appears and stops.
It worked well before, but it doesn't seem to work well after deleting and recreating the Cassandra container.
I think we need to clear the /opt/cassandra/data/commitlog/CommitLog-7-1676434400779.log file.
However, I am not used to using dockers.
How do I erase this file?
I'm not sure if erasing the file will fix the error.
I also asked about this problem in chatgpt. However, after asking a lot of questions for an hour, they told me to try again next time, so I haven't solved it yet. So I'm going to post on Stack Overflow.
So this error likely means that the commitlog file specified is corrupted. I would definitely try deleting it.
If it's on a running docker container, you could try something like this:
Run a docker ps to get the container ID.
Remove the file using docker exec. If my container ID is f6b29860bbe5:
docker exec f6b29860bbe5 rm -rf /opt/cassandra/data/commitlog/CommitLog-7-1676434400779.log
Your question is missing a lot crucial information such as which Docker image you're running, the full Docker command you ran to start the container, and other relevant settings you've configured so I'm going to make several assumptions.
The official Cassandra Docker image (see the Quickstart Guide on the Cassandra website) that we (the Cassandra project) publish stores the commit logs in /var/lib/cassandra/commitlog/ but your deployment stores it somewhere else:
Could not read commit log descriptor in file /opt/cassandra/data/commitlog/CommitLog-7-1676434400779.log
Assuming that you're using the official image, it indicates to me that you have possibly mounted the container directories on a persistent volume on the host. If so, you will need to do a manual cleanup of all the Cassandra directories when you delete the container and recreate it.
The list of directories you need to empty include:
data/
commitlog/
saved_caches/
In your case, it might be just as easy to delete the contents of /opt/cassandra/.
If those directories are not persisted on the Docker host then you can open an interactive bash session into the Cassandra container. For example if you've named your container cassandra:
$ bash exec -it cassandra bash
For details, see the docker exec manual on the Docker Docs website. Cheers!
My sentry version is 22.9.0.
It is downloaded through https://github.com/getsentry/self-hosted.git,Build by docker compose.
I want to clean up historical data to save space.
I checked several methods on the Internet
All are configured by docker exec -it sentry_worker_1 bash or docker exec -it sentry_postgres_1 bash
But these methods are outdated, I did not find the relevant container in my docker container
Later by viewing the configuration file
Try to modify the configuration of SENTRY_EVENT_RETENTION_DAYS in docker-compose.yml in the root directory to 7
docker-compose.yml File Directory
Modify content
After restarting (docker compose down&docker compose up -d), about 50G was cleaned up. Then go to the sentry web to check, everything has been cleared, which is obviously wrong.
enter image description here
question
How to clean up properly
Restart after modifying SENTRY_EVENT_RETENTION_DAYS, why does it still take up so much space
I have installed Sentry onpremise and after some time tinkering I got it to work and changed the system.url-prefix option to the correct URL using the command line. However there are 2 problems still:
This option is not persistant
You cannot do the same for the mail.from option, which can only be set before running.
There are 3 config files at play, but not all of them register and that makes it confusing.
sentry.conf.py
Containing
SENTRY_OPTIONS['system.url-prefix'] = 'https://sentry.mydomain.com'
SENTRY_OPTIONS['mail.from'] = 'sentry#mydomain.com'
config.yml
Containing
mail.from: 'sentry#mydomain.com'
system.url-prefix: 'https://sentry.mydomain.com'
docker-compose.yml
Restarting the containers does not load the new config.
Related issue. However I don't know what to do after changing the config like in the comment (SENTRY_OPTIONS['mail.from'])
You need to make your modified config files visible inside the container.
If they are built into the image (possibly via COPY or ADD in the Dockerfile), then restarting your container does not help, because you're doing it on an old image. You should be rebuilding the image, stopping the old one and starting the new. Rather annoying and error-prone way.
Better way is to "mount" your files via volumes. Docker volumes can be single files, not only directories. You can add the section volumes in your docker-compose.yml:
my_container:
image: my_image
volumes:
sentry.conf.py:/full/path/to/sentry.conf.py/in/the/container
config.yml:/similar/full/path/to/config.yml
ports:
...
command: ...
There's a chance you already have some volumes defined for this particular container (to hold persistent data for example), then you need to simply add volume mappings for your config files.
Hope this helps. All the best in the New Year!
This is how you can edit an existing docker container config:
stop container:
docker stop <container name>
edit config:
docker run -it -v /var/lib/docker:/var/lib/docker alpine vi $(docker inspect --format='/var/lib/docker/containers/{{.Id}}/config.v2.json' <container name>)
restart docker
if the configuration files are stored as docker configs, then I found this guide to work...
https://medium.com/#lucjuggery/about-using-docker-config-e967d4a74b83
Basically add update as a NEW config
tell service to remove the old and then add the new config as the one to use. Service will be restarted
now you can remove the old docker config
this is not very nice, and if you want to name the new config with the old config identifier, you have to repeat it again!
Arrggghhh....
I succesfully installed drupal 7 with docker.
Using docker4drupal, now my question when I start editing my drupal site is, where are the folders containing drupal?
Let's say I installed a new theme and want to swap the images for the banner, how do I access the drupal folder containing the images, or would it be preciser to ask : Where does Docker storage them?
My docker compose line is :
-codebase : /var/www/html
I know that installing it using :
./:/var/www/html
Would install drupal in the same directory my docker-compose.yml is, but for some reason it doesn't work and still doesn't show me where the files are.
Any help is welcome!
If you are not using volumes to mount your existing code, the code resides inside the docker container. You can access it only by getting inside the container using docker exec. If you are using the default docker-compose.yml that came with the repo, then the name of the container will be "docker4drupal_nginx_1" (since nginx is the default).
Run this code to get inside the container:
docker exec -it docker4drupal_nginx_1 /bin/bash
exec allows you to execute commands inside the container.
-it allows you to start an interactive terminal
/bin/bash allows you to start the bash terminal inside the container
Once you are inside container run ls and you will see drupal files including "web".
MORE USEFUL
However, this is not a useful way if you want to work on the files and probably use an editor. Instead, mount a directory on host machine. First make a new directory where your docker-compose.yml file is with the name "codebase".
Then, update the docker-compose.yml so that:
- codebase:/var/www/html
becomes
- ./codebase:/var/www/html
Do this in both php and nginx service definisions. Of course, you should do this after you run docker-compose down with your previous set up. Then restart containers using docker-compose up -d.
Then, you will notice that the Drupal files are present in the codebase directory.
If you see at the bottom of the yml file, you will see that "codebase" is defined as a Docker volume. This implies the storage is managed by Docker and it will get stored somewhere in /var/lib/docker/ along with the container itself.
Hope this helps.
I'm trying to build a Dockerfile for a webapp that uses a file-based database. I would like to be able to mount the file from the host*
The file is in the root of the complete software install, so it's not really ideal to mount that complete dir.
Another problem is that before the first use, the database-file isn't created yet. A first time user won't have a database, but another user might. I can't 'mount' anything during a build** I believe.
It could probably work like this:
First/new database start:
Start the container (without mount).
The webapp creates a database.
Stop the container
subsequent starts:
Start the container using a -v to mount the file
It would be better if that extra start/stop isn't needed for a user. Even if it is, I'm still looking for a way to do this userfriendly, possibly having 2 'methods' of starting it (maybe I can define a first-boot thing in docker-compose as well as a 'normal' method?).
How can I do this in a simpel way, so that it's clear for any first time users?
* The reason is that you can copy your Dockerfile and the database file as a backup, and be up and running with just those 2 elements.
** How to mount host volumes into docker containers in Dockerfile during build
One approach that may work is:
Start the database in the build file in such a way that it has time to create the default file before exiting.
Declare a VOLUME in the Dockerfile for the file after the above instruction. This will cause the file to be copied into the volume when a container is started, assuming you don't explicitly provide a host path
Use data-containers rather than volumes. So the normal usage would be:
docker run --name data_con my_db echo "my_db data container"
docker run -d --volumes-from data_con my_db
...
The first container should exit immediately but set up the volume that is used in the second container.
I was trying to achieve something similar and managed to do it by mounting a folder, instead of the file, and creating a symlink in the Dockerfile, initially pointing to a non-existing file:
docker-compose.yml
version: '3.0'
services:
bash:
build: .
volumes:
- ./data:/data
command: ['bash']
Dockerfile
FROM bash:latest
RUN ln -s /data/.bash_history /root/.bash_history
Then you can run the container with:
docker-compose run --rm bash
With this setup, you can push an empty "data" folder into the repository for example (and exclude its content with .gitignore). In the first run, inside the container /root/.bash_history will be a "broken" symlink, pointing to a file that does not exist. When you exit the shell, bash will write the history to /root/.bash_history, which will end up in /data/.bash_history.
This is probably not the correct approach.
If you have multiple containers that are trying to share some information through the file-system, you should probably let them share some directory.
That way, the flow is simple and very hard to get wrong.
You simply mount the same directory, say /data (from the host's perspective) into all the containers that are trying to use it.
When an application starts and it can't find anything inside that directory, it can gracefully stop and exit with a code that says: "Cannot start, DB not initialized yet".
You can then configure some mechanism with a growing timeout to try and restart that container until you're successful.
On the other hand, the app that creates the DB can start and create it inside the directory or find an existing file to use.