When I use gitlab with docker in the log of the job I can get this information:
Running with gitlab-ci-multi-runner 9.5.0 (413da38)
on platform-docker-orc (2c06225e)
Using Docker executor with image registry:5000/local_image: ...
Using docker image sha256:db4434f2a9c3529af30397031df5bc1277f13882e0f6613a8c8f9c059645c04d for predefined container...
Pulling docker image registry:5000/local_image ...
Using docker image registry:5000/local_image ID=sha256:8d1cac8ae6371b01505e9cd3aaf654696cc144117a9c89dcd21cf4c0d9cfa709 for build container...
Running on runner-2c06225e-project-99-concurrent-0 via a96c0c765ce7...
How can I get the container id where the gitlab job is executed?
You can obtain the container id by leveraging the labels on the container:
docker ps -q -f "label=com.gitlab.gitlab-runner.job.id=$CI_JOB_ID" -f "label=com.gitlab.gitlab-runner.type=build"
Specifying the label=com.gitlab.gitlab-runner.type=build filter will limit it to the build container. Else you will also get services container defined as part of your job.
Related
I'm learning Github Actions and designing a workflow with a job that requires a Service Container.
The documentation states that configuration must specify "The Docker image to use as the service container to run the action. The value can be the Docker base image name or a public docker Hub or registry". All of the examples in the docs use publicly-available Docker images, however I want to create a Service Container from a Dockerfile contained within my repo.
Is it possible to use a local Dockerfile to create a Service Container?
Because the job depends on a Service Container, that image must exist when the job begins, and therefore the image cannot be created by an earlier step in the same job. The image could be built in a separate job, but because jobs execute in separate runners I believe that Job 2 will not have access to the image created in Job 1. If this is true then could I follow this approach, using upload/download-artifact so provide Job 1's image to Job 2?
If all else fails, I could have Job 1 create the image and upload it to Docker Hub, then have Job 2 download it from Docker Hub, but surely there is a better way.
The GitHub Actions host machine (runner) is a fully loaded Linux machine, with everything everybody needs already installed.
You can easily launch multiple containers - either your own images, or public images - by simply running docker and docker-compose commands.
My advice to you is: Describe your service(s) in a docker-compose.yml file, and in one of your GitHub Actions steps, simply do docker-compose up -d.
You can create a docker image with the Dockerfile or docker-compose.yml residing inside the repo. Refer to this public gist, it might be helpful.
Instead of building multiple docker-images, you can use docker-compose. Docker-compose is the preferred way to deal with this kind of scenario.
I see you can untag an image in an Azure Container Registry
https://learn.microsoft.com/en-us/cli/azure/acr/repository?view=azure-cli-latest#az-acr-repository-show-manifests
But how do you add a tag?
You can use import command to import the image in the same repository:
az acr import --name myacr --source myacr.azurecr.io/myimage:latest --image myimage:retagged --force
As far as I know. There is no Azure CLI command to create a tag for the images directly. If you want to add a tag for the image, you just can use the docker command docker tag to add the tag and then push the image to Azure Container Registry.
When you create the image through the build task, it also will lead to the tag adding. Take a look at this.
I had overwrite an existing tag with a latest build inside a release pipeline. So I could not do a build step since its inside a release pipeline. This is my solution hope this helps someone:
This is my release pipeline:
Step 1
task 1: Docker CLI installer
task 2: Docker Task - with login command(log into the ACR)
task 3: Powershell script:
which runs these commands (in my case )
$sourceImage= "acrloginserver/repository:old-tag";
$newtag= "acrloginserver/repository:latest-tag"
docker pull $sourceImage
docker tag $sourceImage $newtag
docker push $newtag`
I have my Docker file , build through it in the Docker engine , and then run the Docker image using docker run -td --name <imagename>
Checks for it, it keeps running in the Docker engine.
But when I tag it to Bluemix and then push it to Bluemix containers(gets available in catalog), and then I ran
cf ic run -td --name ifx2container registry.ng.bluemix.net/namespace_container/ifx2:informixinstall
This creates the container but it gets stopped automatically after few seconds of start
do run docker with
docker run -itd
not with
docker run -td
-i : Keep STDIN open even if not attached
source : https://docs.docker.com/engine/reference/run/
Make sure that your container has a long-running command. Per docs: https://console.ng.bluemix.net/docs/containers/container_planning_container_ov.html#container_planning_images
To keep a container up and running at least one long-running process is required to be included in the container image. For example, echo "Hello world" is a short running process. If no other command is specified in the image, the container shuts down after the command is executed. To transform the echo "Hello world" command into a long running process, you can, for example, loop it multiple times, or include the echo command into another long running process inside your app.
Also, by default containers in Bluemix run in detached mode. You can review supported run flags here: https://console.ng.bluemix.net/docs/containers/container_cli_reference_cfic.html#container_cli_reference_cfic__run
I am connecting to a mysql container using another container running mysql client. When I exit out of this client the container stops obviously. But when I do a docker ps -a this container doesn't show. I have not been able to find a reason for this. I am following these instructions to start the containers. Any ideas would be helpful
The --rm option passed along docker run automatically removes the container after its stopped.
See clean up flag:
By default a container’s file system persists even after the container exits. This makes debugging a lot easier (since you can inspect the final state) and you retain all your data by default. But if you are running short-term foreground processes, these container file systems can really pile up. If instead you’d like Docker to automatically clean up the container and remove the file system when the container exits, you can add the --rm flag
If you look at dockerfiles the often contains lines like this:
sed 's/main$/main universe/' -i /etc/apt/sources.list
I think it is difficult to set up things like this.
Is it possible to launch a default OS image, then enter it interactive with a shell, do some modifications, and then print out the diff (filesystem diff)?
The diff should be used as the dockerfile to recreating the image.
But maybe I am missing something, since I am new to docker.
You can create docker images several ways.
I tend to have two windows open when I create a new docker image. One for my docker run -i -t centos bash, where I am writing all my commands to get it the way I want, and the other one with the Dockerfile, so I can put in whatever I do.
When it comes to config files, I am putting them in the files/folders that matches the one on the image.
Example, if I change /etc/something/file.conf, I will create the file in etc/something/file.conf in the same directory as my Dockerfile, and then use Dockers ADD command to add it whenever I do a build.
This works perfectly, since I can have all this in a git repository with a README.md containing the info I need for running/building the image.
The other thing you can do is to is to run docker ps -a after you are done with the changes you wanted to create an image on, and get the docker ID of the image of the container you just configured. You can tag this new image, or start it with docker run abc0123 bash just like you would a normal docker image.
The problem with this is that you wont be able to easily build it next time without bringing the whole image.
Dockerfiles with ADD is the way to go!
If you do not want to run sed (which is used to preserve the default file and of minimal changes to it), you can simply ADD the modifies file.
For that you can docker run -it --rm thebaseimage /bin/sh (or any other shell that is provided) and edit it in place. Then just copy it outside the container (or docker export it) and use it on your build.
The downside of ADD vs RUN sed… is that, if something changes in a new version of your base image, you will overwrite those changes.
The Dockerfile is (mostly) equivalent to a series of docker run and docker commit commands. You wouldn't want to look at the docker diff to see what files changed -- you'd want to see what docker run commands had occurred. You could get these from your host shell history and process these into a Dockerfile.