I have not tested this, but AFAIK you should not experience any data loss if you just replace the docker-compose file and do an docker compose up …
The container names have not been changed and the mount points for the volumes have not, too, thus all your data should be available independent from where you load the images from …!
The project name has changed from greenbone-community-edition to greenbone-community-container. Thus the mountpoint has also changed (gvmd data volume as example) from /var/lib/docker/volumes/greenbone-community-edition_gvmd_data_vol/_data to /var/lib/docker/volumes/greenbone-community-container_gvmd_data_vol/_data.
user@host:~# docker volume inspect greenbone-community-edition_gvmd_data_vol
[
{
"CreatedAt": "2023-09-29T15:24:17+02:00",
"Driver": "local",
"Labels": {
"com.docker.compose.project": "greenbone-community-edition",
"com.docker.compose.version": "2.22.0",
"com.docker.compose.volume": "gvmd_data_vol"
},
"Mountpoint": "/var/lib/docker/volumes/greenbone-community-edition_gvmd_data_vol/_data",
"Name": "greenbone-community-edition_gvmd_data_vol",
"Options": null,
"Scope": "local"
}
]
user@host:~# docker volume inspect greenbone-community-container_gvmd_data_vol
[
{
"CreatedAt": "2024-10-01T09:41:43+02:00",
"Driver": "local",
"Labels": {
"com.docker.compose.project": "greenbone-community-container",
"com.docker.compose.version": "2.22.0",
"com.docker.compose.volume": "gvmd_data_vol"
},
"Mountpoint": "/var/lib/docker/volumes/greenbone-community-container_gvmd_data_vol/_data",
"Name": "greenbone-community-container_gvmd_data_vol",
"Options": null,
"Scope": "local"
}
]
I’m not really experienced with Docker, so I’m looking for a way to migrate currently.
— EDIT —
That’s what happens when you don’t pay attention and just run docker compose down, docker compose pull and docker compose up.
Short version: Make sure to run docker compose -f $DOWNLOAD_DIR/docker-compose.yml -p greenbone-community-edition pull and docker compose -f $DOWNLOAD_DIR/docker-compose.yml -p greenbone-community-edition up -d instead of docker compose pull and docker compose up.
Long version: Per the Greenbone Community Containers documentation, the $DOWNLOAD_DIR is defined as greenbone-community-container. According to the Docker documentation, “the default project name is derived from the base name of the project directory”, which also takes effect on the Docker volume names and locations. All commands in the documentation are using the -p switch to explicitly set the project name to greenbone-community-edition. So since the project names don’t match any longer, fresh volumes are created.
In my opinion, this could be mitigated by the $DOWNLOAD_DIR having the same name as the project name that is set explicitly each time, but in the end it’s just a layer 8 problem.
2 Likes
You are correct.
We have not specified a name: attribute in the docker-compose.yml file, thus I thought, that there was no problem in migration. But I just saw, that we switched from greenbone-community-edition to greenbone-community-container for the $DOWNLOAD_DIR as stated by you already! (Second) but we did not do this change recently, I will need some more time to identify when we changed this!
Nevertheless greenbone-community-container is the correct name and maybe your compose-file download has been made some time ago?
1 Like
The $DOWNLOAD_DIR hasn’t changed as far as I can see looking at the WayBackMachine. At least in a snapshot from the 9th of August 2022 it’s already greenbone-community-container.
The issue was wholly on my part: I omitted the -p greenbone-community-edition in my docker pull command, so the project name was automatically set according to the directory name greenbone-community-container, making it a separate project. Check the edit of my previous reply for more in-depth info.
2 Likes