How to use Gitlab and rancher to build CI/CD pipelining –part 2__gitlab

This is the second part of the series of tutorials that we use Gitlab and rancher to build CI/CD pipelining. The first part describes how to deploy, configure, and ensure that Gitlab runs in rancher. In this section, we will describe how to build the container using the Gitlab CI Multi-runner, and how to configure the project using the Gitlab container registry. In addition, we will also cover how to use Gitlab ci to build containers and deploy them to rancher. building containers using Gitlab CI multi-runner

Gitlab CI is a powerful tool for continuous integration and continuous delivery. It needs to be used in conjunction with rancher, where we will deploy a runner to perform the job. Run Runner

There are several ways to deploy runner, but given that our goal is to build containers from our own repositories, we will run a Docker container that can directly access/var/run/docker.sock to build a mirror of its own synchronization. In rancher, add a service to your Gitlab stack. Use the following configuration to set up:
Name:runner01 Image:gitlab/gitlab-runner console:none Volumes:
/var/run/docker.sock:/var/run/docker.sock
Runner01-etc:/etc/gitlab-runner

When the container runs, it creates a default configuration in the/etc/gitlab-runner that corresponds to the volume that we have established the connection to. Next, register the runner with your Gitlab instance.

In the following operation, I set the configuration for the basic runner, which can be used to build any job. You can also limit the runner to a specified repository or use a different mirror. Here you can read Gitlab's documentation to find out what is best for your environment. Configure runner to execute shell runs in the container Gitlab-ci-multi-runner register to start registration follow the prompts, and refer to the following example (the answer is in bold)

The

root@4bd974b1c799:/# gitlab-ci-multi-runner Register
Running in System-mode.
Please enter the GITLAB-CI Coordinator URL (e.g. https://gitlab.com/):
https://git.example.com
Please enter the Gitlab-ci token for this runner:
dgq-j7n0tr33lxb3z_
Please ente R the Gitlab-ci description for this runner:
4bd974b1c799]: runner01
Please enter the GITLAB-CI Tags for this runner (comma separated):
< press enter>
Whether to lock runner to Project [True/false]:
[false]: < press Enter>
Registering runner ... succeeded Runner=dgq-j 7dD
Please enter the Executor:docker, parallels, SSH, Docker-ssh+machine, kubernetes, docker-ssh, Shell, VirtualBox, Docker+machine:
Docker
Please enter the default Docker image (e.g. ruby:2.1):
doc Ker:stable
Runner registered successfully.

Go ahead and execute them, and if runner is already running, then the configuration will automatically reload. Here to focus on: input your Gitlab instance URL input Runner token (found in admin/runners) give runner a recognizable name Select Runner Docker type selection docker:stable container mirroring

After the initial registration is complete, we need to edit the/etc/gitlab-runner/config.tom and make adjustments: volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/ Cache "]

This loads the/var/run/docker.sock in the container so that the built container is saved in the mirrored storage of the host itself. This is a better way than Docker.

CONFIG.TOML modifications are performed automatically by runner, so no reboot is required.

You can see your runner and interact with it under the admin/runners. Configuring items using container mirroring warehouse

The Gitlab container mirroring warehouse is bound directly to the repository, so the container cannot be transferred to any other location. If you have a repository named Demo-pho in the Docker group, the path to the mirror is registry.example.com/docker/demo-php, where the label is defined based on how you created the container with Gitlab ci.

For the remainder of this tutorial, I'll use a repository with content that can be found in GitHub. You need to do the following to start it in your Gitlab environment: Create a project in Gitlab. In this tutorial, I named it Example/demo (workgroup is example, Project is demo) clone and modify Rancher-gitlab-demo repository

$ git clone https://github.com/oskapt/rancher-gitlab-demo.git demo
$ cd demo
$ git Remote Set-url origin ssh://gi T@git.example.com:2222/example/demo.git
$ Git push-u Origin Master

The file looks like this:

variables:registry_host:registry.example.com test_image: $REGISTRY _host/$CI _project_ PATH: $CI _build_ref_name release_image: $REGISTRY _host/$CI _project_path:latest stages:-Build-release Before_script :-Docker info-docker login-u gitlab-ci-token-p $CI _build_token _host $REGISTRY build:stage:build script:-
   Docker build--pull-t $TEST _image. -Docker push $TEST _image release:stage:release script:-Docker pull $TEST _image-docker tag $TEST _image $REL Ease_image-docker push $RELEASE _image only:-Master Push_to_docker_hub: # into order ' for ' to work your'll n Eed to set # ' Hub_username ' and ' Hub_password ' as CI variables # in the Gitlab project Stage:release  Cker_image: $HUB _username/$CI _project_name:latest script:-Docker login-u $HUB _username-p $HUB _password-docker Tag $RELEASE _image $DOCKER _image-docker push $DOCKER _image only:-Master when:manual 

The CI file I designed can be used in a number of basic Docker projects without any modification. After you set the variable portion of the item to the value you want, the rest of the file can be applied to any project.

There are two phases-build and publish. Gitlab has its own token that allows you to log in to your own mirrored warehouse, which is executed in the Before_script section. It then executes script commands in the build phase, builds the container, and marks the container with the format specified in the Test_image variable. This gets a container with a branching name, just like our develop branch:

Registry.example.com/example/demo:develop

The container information is then pushed into the mirrored warehouse.

If it is the master branch, it performs all of these steps, and in the release phase, it continues to use the latest tag mirror before it is added to the mirrored warehouse. This way you will get a container that marks both master and lastest. Where lastest is the default label name, you can get it without specifying a label name.

Finally, the master branch has a manual option available to push the container to the Docker Hub. To achieve this, you first need to be in the settings in the Gitlab project | CI/CD Pipelines | Secret variables set hub_username and Hub_password. Gitlab CI will mark the master mirror based on the value of Docker_image, and then push it to the Docker Hub. Since we have specified that the Manual,gitlab of the When is not automatically performed, you must manually perform this phase from Gitlab. build containers through Gitlab ci

In the develop branch, you can submit these changes and push them to your Gitlab project. If everything works, you can see the pipeline start under the Pipelines tab of the project. You can select the status icon to view the detailed progress log under this phase.

If any errors occur, Gitlab CI will report pipeline failure, and you can view the log to see why. When a problem is resolved and a new commit is pushed, Gitlab CI launches the new pipeline. If the error is temporary (such as inability to connect to the Docker Hub), you can run the pipeline again at that stage.

If you just want to run pipeline from existing code, you can click Run Pipeline and select the branch you want to build.

When all is done, the pipe will show passed, and you can see your container under the Registry tab of the Gitlab project. Create a deployment user

Before using the mirrored warehouse, you need to add the deployment user to the rancher. I recommend that you create a deploy user with reporter permissions on the project you want to deploy, rather than using your administrator account. Click the wrench icon in the upper right corner to enter the admin area the new User button that hits the bottom of the column creates a user named deploy that the user is external under access. This will provide users with restricted access in Gitlab. Click Create User to enter the summary interface

Gitlab will send a login email to the user by default, so we need to edit the user and set the password. In the summary interface, click Edit in the upper-right corner to set the password for the user, then click Save Changes to navigate to your item in Gitlab, click the members to type deploy in the Search field and select Deploy user Reporter permissions to users click Add to Project Save changes

The Deploy user now has the right to access the container from your project's container registry. Deploy container to rancher

All we've done so far is take this step-get the container from your private mirrored warehouse and deploy it to the rancher. The last thing we need to do is add a mirrored warehouse and then do a new stack and service. In rancher, click Infrastructure and select Registries Click Add Registry Select Custom enter your registry URL (for example, example.com) Enter your user name and password for your deployment user create

After you add the mirrored warehouse to the rancher, you are ready to create the service from these mirrors. Create a stack named demo to add a service, the name is up to you. Let the mirror use the develop tag in your new container mirror
Example.com/example/demo:develop Click Create

Congratulations to you. You've just already deployed the development version of your project with a private container mirrored warehouse. What can you do from here?

This is a lengthy tutorial, but when all the important steps are complete, you can start working with the tools that are already installed. From now on you can do these things: Set up workgroups for your other projects. For the items that will be included, you can use a logical collection, like Docker or websites. Import other projects into Gitlab set up Gitlab ci to build containers Modify Master Branch, merge develop branch, introduce. GITLAB-CI.YML, and push it to Gitlab. Update rancher to get the lastest mirror label. Add Hub_username and Hub_password to your project, and then manually push your mirrors to the Docker Hub

Original Source: Rancher Labs

September 27, Beijing Hna Marriott Hotel, container Technology conference container Day 2017 is about to be held.

Cloudstack's father, HNA technology director, Huawei PAAs Department minister, general manager of Hengfeng Bank Science and technology, Aliyun PAAs Engineering Director, Minsheng Insurance CIO Have joined the deluxe instructor package.

11 container Landing Enterprises, 15 real cloud computing, 13 pure technical speech, combined with actual combat scene, focus on landing experience. Free Attendance + Super HIGH specification, detailed agenda and registration link please stamp