I've been trying to wrap my head around some old CI/CD scripts my company has written previously, to deploy some applications. The gitlab pipeline has several stages, as is seen in the beginning of the .gitlab-ci.yml file:
image: docker:stable
variables:
DOCKER_DRIVER: overlay2
CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_API: $CI_REGISTRY_IMAGE/career_api:latest
CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_APP: $CI_REGISTRY_IMAGE/career_app:latest
CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP: $CI_REGISTRY_IMAGE/career_dev_app:latest
CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_API: $CI_REGISTRY_IMAGE/career_dev_api:latest
# from https://storage.googleapis.com/kubernetes-release/release/stable.txt
K8S_STABLE_VERSION_URL: https://storage.googleapis.com/kubernetes-release/release/v1.18.4/bin/linux/amd64/kubectl
stages:
- prebuild
- test
- transform
- build
- deploy
Then, later on, the file specifies all these stages for a DEV and a MASTER branch. Specifically, I have trouble understanding the script in the prebuild stage of the dev branch:
prebuild_dev:
stage: prebuild
extends: .prebuildreq
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker pull $CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP || true
- docker build -f Dockerfile --pull -t $CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP --cache-from $CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP .
- docker push $CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP
only:
refs:
- dev
tags:
- testcicd
How I see it now is that the gitlab runner is ran as docker container? (Signified by the image:docker and DOCKER_DRIVER:overlay2 in the beginning of the file). Then, in the prebuild stage it does 4 steps:
login to the container registry with predefined vars $CI_REGISTRY_USER, $CI_REGISTRY_PASSWORD, and $CI_REGISTRY.
Pull CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP from this registry. First question: What does || true do here?
Build a dockerfile but also pull $CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP? Second question: What is happening in this line?
push image (The pulled one or the built one?) back to container registry
Some help to understand this would be greatly appreciated.
docker pull $CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP || true
i assume not 100% sure, not to fail command if docker pull image doesn't exist.
Question : 1
docker build -f Dockerfile --pull -t
$CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP --cache-from
$CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP .
Docker build --pull fetch the specified image digest always for the base image. Instead of using the local version.
Consider it like your base image available at your Build Jenkin machine but it won't use and pull again.
note : --pull --no-cache are flags, you wont be passing any values with it.
Like we do with docker -t or docker -p
Question : 2
docker build -f Dockerfile --pull -t
$CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP --cache-from
$CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP .
$CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP is not pulling image, after -t it's tagging the image with name.
Question : 3
push image (The pulled one or the built one?) back to container
registry
Build one since you have tag image with $CONTAINER_RELEASE_IMAGE_CAREER_GROWTH_DEV_APP
Related
I am learning GitLab-ci and a few things puzzle me.
So here is a build job I found while googling:
.build:
before_script:
- echo "$CI_REGISTRY_PASSWORD" | docker login --username $CI_REGISTRY_USER --password-stdin $CI_REGISTRY
script:
- docker pull $CI_REGISTRY_IMAGE/$IMAGE_NAME:latest || true
- docker build --ssh default --cache-from $CI_REGISTRY_IMAGE/$IMAGE_NAME:latest --build-arg BUILDKIT_INLINE_CACHE=1 --tag $CI_REGISTRY_IMAGE/$IMAGE_NAME:latest --tag $CI_REGISTRY_IMAGE/$IMAGE_NAME:$CI_COMMIT_SHORT_SHA .
- docker push $CI_REGISTRY_IMAGE/$IMAGE_NAME:$CI_COMMIT_SHORT_SHA
- docker push $CI_REGISTRY_IMAGE/$IMAGE_NAME:latest
stage: build
image: docker:stable
services:
- docker:dind
needs: []
Why before the building image is being pulled and pipe to true? I imagine it has something to do with caching but I am not sure why to use a pipe to true.
Also, what is the purpose of --ssh default and BUILDKIT?
You should pull the image to take advantage of cached layers so that you don't build layers again unnecessarily. This results in faster builds, faster updates for people pulling new images, and more efficient use of storage in your container registry.
You can read more about this in the GitLab docs: Make Docker-in-Docker builds faster with Docker layer caching
For your additional questions:
Regarding --ssh default: see the docker documentation on this.
Regarding BUILDKIT, in short, in enables faster and more efficient builds.
A very typical scenario with GitLab CI is to install a few packages you need for your jobs (linters, code coverage tools, deployment-specific helpers and so on) and to then run your actual stages/steps of a building, testing and deploying your software.
The Docker runner is a very neat and clean solution, but it seems very wasteful to always run the steps that install the base software. Normally, Docker is able to cache such layers, but with the way the GitLab Docker runner works, that doesn't happen.
Do we realize that setting up another project to produce pre-configured Docker images would be one solution, but are there any better ones? Basically, what we want to say is: "If the before section hasn't changed, you can reuse the image from last time, no need to reinstall wget or whatever".
Any solution like that out there?
You can use the registry of your gitlab project.
eg.
images:
stage: build
image: docker
services:
- docker:dind
script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY # login
# pull the current image or in case the image does not exit, do not stop the script:
- docker pull $CI_REGISTRY_IMAGE:latest || true
# build with the pulled image as cache:
- docker build --pull --cache-from $CI_REGISTRY_IMAGE:latest -t "$CI_REGISTRY_IMAGE:latest" .
# push the final image:
- docker push "$CI_REGISTRY_IMAGE:latest"
This way docker build will profit from the work done by the last run of the job. See the docs. Maybe you want to avoid unnecessary runs by some rules.
I recently got into CI/CD, and a good starting point for me was GitLab, since they provide an easy interface for that and i got started about what pipelines and stages are, but i have run into some kind of contradictory thought about GitLab CI running on Docker.
My app runs on Docker Compose. It contains (blah blah) that makes it easy to build & run containers. Each service in the Docker Compose creates a single Docker container, excepting the php-fpm one, which is able to do the thing called "horizontal scale", so I can scale it later.
I will use that Docker Compose for production, I am currently using it in development and I want to use it too in CI/CD pipelines.
However the .gitlab-ci.yml provides support for only one image, so I have to build it and push it to either their GitLab Registry or Docker Hub in order to pull it later in the CI/CD process.
How can I build my Docker Compose's service as a single image in order to push it to the Registry/Docker so I can pull it in the CI/CD?
My project contains a docker folder and a docker-compose.yml. In the docker folder, each service has its own separate directory (php-fpm, nginx, mysql, etc.) and each one (prepare yourself) contains a Dockerfile with build details, especially the php-fpm one (deps and libs are strong with this one)
Each service in the docker-compose.yml has a build context in each of their own folder.
If I was unclear, I can provide additonal info.
However the .gitlab-ci.yml provides support for only one image
This is not true. From the official documentation:
Your image will be named after the following scheme:
<registry URL>/<namespace>/<project>/<image>
GitLab supports up to three levels of image repository names.
Following examples of image tags are valid:
registry.example.com/group/project:some-tag
registry.example.com/group/project/image:latest
registry.example.com/group/project/my/image:rc1
So the solution to your problem is simple - just build individual images and push them to GitLab container registry under different image name.
If you would like an example, my pipelines are set up like this:
.template: &build_template
image: docker:stable
services:
- docker:dind
before_script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
script:
- docker pull $CI_REGISTRY_IMAGE/$IMAGE_NAME:latest || true
- if [ -z ${CI_COMMIT_TAG+x} ];
then docker build
--cache-from $CI_REGISTRY_IMAGE/$IMAGE_NAME:latest
--file $DOCKERFILE_NAME
--tag $CI_REGISTRY_IMAGE/$IMAGE_NAME:$CI_COMMIT_SHA
--tag $CI_REGISTRY_IMAGE/$IMAGE_NAME:$CI_COMMIT_TAG
--tag $CI_REGISTRY_IMAGE/$IMAGE_NAME:latest . ;
else docker build
--cache-from $CI_REGISTRY_IMAGE/$IMAGE_NAME:latest
--file $DOCKERFILE_NAME
--tag $CI_REGISTRY_IMAGE/$IMAGE_NAME:$CI_COMMIT_SHA
--tag $CI_REGISTRY_IMAGE/$IMAGE_NAME:latest . ;
fi
- docker push $CI_REGISTRY_IMAGE/$IMAGE_NAME:$CI_COMMIT_SHA
- if [ -z ${CI_COMMIT_TAG+x} ]; then
docker push $CI_REGISTRY_IMAGE/$IMAGE_NAME:$CI_COMMIT_TAG;
fi
- docker push $CI_REGISTRY_IMAGE/$IMAGE_NAME:latest
build:image1:
<<: *build_template
variables:
IMAGE_NAME: image1
DOCKERFILE_NAME: Dockerfile.1
build:image2:
<<: *build_template
variables:
IMAGE_NAME: image2
DOCKERFILE_NAME: Dockerfile.2
And you should be able to pull the same image using $CI_REGISTRY_IMAGE/$IMAGE_NAME:$CI_COMMIT_SHA in later pipeline jobs or your compose file (provided that the variables are passed to where you run your compose file).
You don't need dind to run a docker-compose stack. You can run multiple docker-compose up commands.
acceptance_testing:
stage: test
before_script:
- docker-compose -p $CI_JOB_ID up -d
script:
- docker-compose -p $CI_JOB_ID exec -T /run/your/test/suite.sh
after_script:
- docker-compose -p $CI_JOB_ID down -v --remove-orphans || true
I think you search something like this
# .gitlab-ci.yml
image: docker
services:
- docker:dind
build:
script:
- apk add --no-cache py-pip
- pip install docker-compose
- docker-compose up -d
Also good to know:
In Docker, what's the difference between a container and an image?
Building Docker images with GitLab CI/CD
I have a project of Drupal which contains two images: one for Drupal source code & another for MySQL database.
I tagged them:
docker build -t registry.mysite.net/drupal/blog/blog_db:v1.3 mysql/db
docker build -t registry.mysite.net/drupal/blog/blog_drupal:v1.3 src/drupal
Where registry.mysite.net is the url of the git site, and can be found under Container registry settings.
drupal is the group name,
blog is the project name,
blog_db is the image for database, mysql/db is the location for the Dockerfile, and likewise for the other image.
And then to push it to gitlab use:
docker push registry.mysite.net/drupal/blog/blog_db:v1.3
docker push registry.mysite.net/drupal/blog/blog_drupal:v1.3
Hope this might help someone.
My school has a personal gitlab setup, but it doesn't have a registry setup for docker images.
What I want to do is run my pipeline with docker, so that I can build, test etc in a docker environment.
Right now i am trying random stuff because I don't know what I am doing. This is what I have now:
Gitlab-ci:
image: docker:latest
services:
- docker:dind
before_script:
- docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
build-master:
stage: build
script:
- docker build --pull -t "$CI_REGISTRY_IMAGE" .
- docker push "$CI_REGISTRY_IMAGE"
build:
stage: build
script:
- docker build --pull -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG" .
- docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG"
My secret variables on gitlab:
My error message in the pipeline:
Something else I tried uses a gitlab repo. This uses the docker image for ros correctly, but in my application I also use opencv, so I want to add more to the docker image. If i know how to do that in the example below, thats also an option. On top of this, in the example below i can't run tests.
Gitlab-ci:
image: ros:kinetic-ros-core
stages:
- build
variables:
ROS_PACKAGES_TO_INSTALL: ""
USE_ROSDEP: "true"
cache:
paths:
- ccache/
before_script:
- git clone https://gitlab.com/VictorLamoine/ros_gitlab_ci.git
- source ros_gitlab_ci/gitlab-ci.bash
catkin_make:
stage: build
script:
- catkin_make
catkin_build:
stage: build
script:
- catkin build --summarize --no-status --force-color
As I said I have tried many things, this is just the latest thing I have tried. How can I run my runners and gitlab-ci with docker without a gitlab registry?
Just use it withouth registry.
You just need to insert this to gitlab runner config file:
pull_policy = "if-not-present"
Thats enough, and remove commands like:
docker push ...
docker pull ...
Or even insert "|| true" at the end of the push pull command if you want to keep push pull in case, like this:
docker pull ... || true;
Which keeps your code to continue if command fail.
Just dont forget that : pull_policy = "if-not-present" , which allow You to run docker image withouth pull and push.
As image is in case if mussing builded, this works.
example:
[[runners]]
name = "Runner name"
url = ...
...
executor = "docker"
[runners.docker]
image = ...
pull_policy = "if-not-present"
...
You can change these secret variables to point to docker-hub registry server.
You have to create your account on that https://hub.docker.com/ and then use that details to configure - gitlab secret variables.
Been trying to set-up Gitlab CI which can build a docker image, and came across that DinD was enabled initially only for separate runners and Blog Post suggest it would be enabled soon for shared runners,
Running DinD requires enabling privileged mode in runners, which is set as a flag while registering runner, but couldn't find an equivalent mechanism for Shared Runners
The shared runners are now capable of building Docker images. Here is the job that you can use:
stages:
- build
- test
- deploy
# ...
# other jobs here
# ...
docker:image:
stage: deploy
image: docker:1.11
services:
- docker:dind
script:
- docker version
- docker build -t $CI_REGISTRY_IMAGE:latest .
# push only for tags
- "[[ -z $CI_BUILD_TAG ]] && exit 0"
- docker tag $CI_REGISTRY_IMAGE:latest $CI_REGISTRY_IMAGE:$CI_BUILD_TAG
- docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY
- docker push $CI_REGISTRY_IMAGE:$CI_BUILD_TAG
This job assumes that you are using the Container Registry provided by Gitlab. It pushes the images only when the build commit is tagged with a version number.
Documentation for Predefined variables.
Note that you will need to cache or generate as temporary artifacts of any dependencies for your service which are not committed in the repository. This is supposed to be done in other jobs. e.g. node_modules are not generally contained in the repository and must be cached from the build/test stage.