I am trying to upgrade a NXRM3 repository which is running on a docker container with a persistent volume attached to it. The existing docker container is a custom built image by adding couple of plugins through Dockerfile. I want to build the latest version image with those newer version plugins and run NXRM3 on the updated version, but how do i use the same volume with the new container? Can i attach the volume to the new container and does that work? Any help regarding the safest process is much appreciated. Thanks in advance.
Below is the docker-compose file for the existing version:
services:
nexus:
container_name: nexus
build: .
ports:
- "8080:8080"
- "8081:8081"
- "8082:8082"
volumes:
- "nexus-data:/nexus-data"
restart: unless-stopped
volumes:
nexus-data:
The volume exists independently of the container. So just create the new image and create a new container based on it with the original volume attached. To be completely on the safe side you can make a backup of the volume.
In case you keep the images in Nexus as well, be careful to have it available on the host before you bring down the old Nexus container.
Related
I have an app developped in .Net Core et i use Docker to Deploy it in Linux VPS.
In The app, i have a feature that consists on uploading files and i store them in wwwroot. I have used docker volumes to externalize the folder.
But everytime i did a build i loose all the files that users uploaded. Which is normal..
Update: This is how i'm declaring the volume
app:
image: app
depends_on:
- "postgres_image"
build:
context: .
dockerfile: Dockerfile
ports:
- "5000:5000"
volumes:
- app_wwwroot:/wwwroot
My question is what is the best approach to be able to make changes on the app (build source code and get a new release) without loosing the uploaded files.
Thanks.
It would've been better if you provided how you are using docker volumes to persist the wwwroot data.
If you want to persist your data you can either use bind mounts or volumes within the docker run command or the docker-compose.
I usually use bind mounts instead of volumes when I want to persist data:
docker run -v './path/on/your/machine:/path/inside/the/container' image_name
or In docker compose
version: '3.8'
services:
app:
image: image_name
volumes:
- './path/on/your/machine:/path/inside/the/container'
as you can see you will be mounting ./path/on/your/machine from your host machine into /path/inside/the/container which is the data of wwwroot in your case.
Any changes made on each one of the dir/file mapped inside the container or your host machine will affect both.
Building again wouldn't affect the dir/file
I'm trying to write a docker-compose file that will build and push a versioned (1.0, 1.1...) and latest build of my image to my local v2 docker registry. However when I run docker-compose build I get the following error:
ERROR: Couldn't connect to Docker daemon - you might need to run `docker-machine start default`.
I found a lot of people complaining about this error for many different reasons, in my case it has nothing to do with permissions or weather or not the docker service is running, I narrowed it down to my image naming having a URL on it (the URL of my local registry), I know that because if I name my image normally (like '/app:latest'), then the commands runs fine. So how can I have a URL as the image name?
Here is what I'm trying to do (docker-compose.yaml):
version: "3.8"
x-marvin-backend: &default-marvin-backend
container_name: marvin_backend
build: ./marvin-api
image: "http://my_registry_url:5000/marvin/backend:latest"
ports:
- "3000:3000"
networks:
- backend
x-marvin-frontend: &default-marvin-frontend
container_name: marvin_frontend
image: http://my_registry_url:5000/marvin/frontend:latest
build:
context: ./marvin-front
args:
- REACT_APP_SERVICES_HOST=http://marvin_backend:3000/
ports:
- "80:80"
networks:
- backend
depends_on:
- backend
services:
backend: *default-marvin-backend
backend_versioned:
<< : *default-marvin-backend
image: http://my_registry_url:5000/marvin/backend:1.0
frontend: *default-marvin-frontend
frontend_versioned:
<< : *default-marvin-frontend
image: http://my_registry_url:5000/marvin/frontend:1.0
networks:
backend:
I'm new to docker in general, my main goal here is to have a simple, preferably one command (e.g docker-compose build), that will build and tag both my front end and back end images so that I can just execute docker-compose push to push those newly created images to my registry running on AWS. With that I also want to be able to override the latest version of those images in the registry while also adding a versioned image for backup purposes, in case I want to revisit any of those version in the future.
Then in the AWS EC2 machine I have another docker-compose.yaml file that just fetches the latest versions of both images and run their containers.
So to summarize I would develop the application on my local machine, then add the new version manually to the versioned services in the local docker-compose.yaml file, then run docker-compose build followed by docker-compose push; then ssh into my AWS machine and run docker-compose up to fetch the latest and newly updated images and run them.
This could later evolve into a CI/CD pipeline, but right now I'm taking baby steps and trying to get my image name to have a URL in it.
Thank you.
Edit
I tried using a .env with REGISTRY=http://my_registry_url:5000/marvin and then using image: "${REGISTRY}/frontend:latest" or image: "$${REGISTRY}/frontend:latest" but that also didn't work
Just remove the http:// part from your images.
The use case for me is that I need to use the containers of 3rd party services like Mongodb and InfluxDb as a part of my complete docker service setup. The containers from these 3rd party services may or may not exists in my machine. I want to use the same container and prevent docker compose from recreating them if they already exists and recreate them if they don't exist.
I have created a docker compose file as below:
version: "3.7"
services:
mongo-database:
container_name: mongo
image: mongo:${Mongo_Service_Version}
restart: always
ports:
- "30041:27017"
networks:
- internal-network
volumes:
- data:/data/db
service-test:
container_name: service-test
image:service1:v1
restart: always
ports:
- "30091:80"
networks:
- internal-network
depends_on:
- mongo-database
I have created a mongo service and then created an application service-test that depends on the mongo service.
(Note : Service-test is just for demonstration purpose)
The problem I face is that when I run the docker-compose command to up the service I am able to do it successfully. The docker compose first creates a mongo container and then a service container but the problem is that if a mongo container with the same name and same configuration already exists the docker compose gives the error that the container with same name already exists.
My use case is that i don't want to remove the old container manually and recreate it using docker-compose. My expectation is that docker compose is smart enough to handle this situation. Docker compose should not try to recreate the container if it already exists.
If there is just the service version upgrade and we run the docker compose command , docker compose behave smart and does not recreates the mongo container but why it does not acts smart when the mongo container is created separately/manually.
I'm developing locally on a Windows 10 PC, and have Docker images installed on drive D.
Running the command 'docker images' shows...
When I run a 'docker-compose up' command I'm getting the following error...
Pulling eis-config (eis/eis-config:)...
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]
Any idea why this is happening? (Could it be that the docker-compose is looking for the images on docker-hub, rather than locally?
The 'docker-compose.yml' file is shown below...
version: "3.7"
services:
eis-config:
image: eis/eis-config
ports:
- "8001:8001"
eis-eureka:
image: eis/eis-eureka
ports:
- "8761:8761"
depends_on:
- eis-config
eis-zuul:
image: eis/eis-zuul
ports:
- "8080:8080"
depends_on:
- eis-eureka
gd-service:
image: eis/gd-service
ports:
- "8015:8015"
depends_on:
- eis-eureka
run
docker-compose kill
docker-compose down
docker-compose up
should fix your issue, most likely you have an old container (running or not) that's causing the problem
You are running eis/eis-config without an Image tag, so latest is implicitely assumed by docker. You don't have an Image eis/eis-config with latest tag. So either build your Image with latest tag, or run image: eis/eis-config:0.0.1-SNAPSHOT
It seems like you missed an entry for the eis/eis-config service in the yml file, once check your yml file and regenerate the image for that service.
Where are you trying to run those images, locally in your machine or on a remote server?
once look at this link Error running containers with docker-compose, error pulling images from my private repo in dockerhub
I have a docker-compose.yml file which takes the image svka4019/notes2:latest from the docker hub.
However, if I change the image build it and push it, when I run docker-compose it just uses the one it has already downloaded before.
Here is the docker-compose.yml:
springboot-docker-compose-app-container:
image: svka4019/notes2:latest
ports:
- "80:5001"
depends_on:
- friendservice
networks:
- mynet
container_name: base_notes
friendservice:
build: ./Pirmas
command: python app.py
ports:
- 5000:5000
container_name: friend
networks:
- mynet
networks:
mynet:
And the command I use for building and running: docker-compose up --build -d.
For updating the image in docker-hub I use:
docker build -t svka4019/notes2
docker push svka4019/notes2
If I use methods as no-cache it just rebuilds friendService container and skips the base one.
As #DazWilkin pointed out in the comments, using latest tag should be used carefully. Not only can it introduce bugs in your app if latest comes with BC breaks, but it also doesn't indicate that a new update must be performed on your machine if you already have an image 'latest'.
In your case, what you have to do should you want to keep using latest, is to simply call:
docker-compose pull
In case you are building your own image, then you must do:
docker-compose build --pull
The latter will tell docker-compose to first pull the base image before building your custom image.