Posted on Leave a comment

CI/CD operations – /usr/bin/oc permission denied

When you get a failure from your CI/CD pipeline regarding permission denied reasons, you should change them accordingly so that all users could access the oc tool.

The resolution is to provide 751 permissions or any other needed, but make some that user that executes the pipeline will be able to run the oc tool. Personally I added execute for others and I could bypass the error.

Posted on Leave a comment

Create a CI/CD pipeline with Gitlab on container deployments

In order to create a CI/CD pipeline with gitlab built-in functionality you should firstly create the appropriate .gitlab-ci.yml file. This is the file on which the steps will be described for the pipeline.

This file should be placed on the root structure of the branch and every time a commit is pushed on the remote repository the steps will run. Instructions have been provided from gitlab and can be found here

For this example I chose gitlab runner as the building tool and the deployment method of a docker container.

In order to install gitlab runner as a container perform the below steps:

Download the image.

 docker run -d --name gitlab-runner --restart always \
     -v /srv/gitlab-runner/config:/etc/gitlab-runner \
     -v /var/run/docker.sock:/var/run/docker.sock \
     gitlab/gitlab-runner:latest

Create a persistent volume

docker volume create gitlab-runner-config

Stop the container if already started from previous step and run it again with the mapped volume

docker run -d --name gitlab-runner --restart always \     -v /var/run/docker.sock:/var/run/docker.sock \     -v gitlab-runner-config:/etc/gitlab-runner \     gitlab/gitlab-runner:latest

You will see the container running

Register gitlab with your runner. You should get the registration token and runner url from your repository settings.

Inspect container and press gitlab-runner register

Start the runner

gitlab-runner start

The runner should have been registered on your gitlab environment

Perform a commit and push changes to your repository

The run task should have started

Check the pipeline and see its status

The job was not succesful and by checking the logs I could verify that DNS resolution could not be enstablished.

In order to fix that you should add an entry for your named gitlab container to your gitlab runner. Unfortunately there are no tools like vim, nano installed on gitlab-runner. However you can bypass this by echoing a value in your /etc/hosts file.

It is also important that your local computer can resolve by fqdn your gitlab deployment. This is necessary because docker should be able to read this entry and perform actions on it.

After those changes you will be able to run your pipeline successfully.

Posted on 1 Comment

Provision gitlab-ce on docker with Portainer

Portainer is a fantastic tool that includes a GUI in order to manage your container workloads easier than with command line. It is free to use with a community edition and the documentation describes the installation which will take one approximately 5 minutes to complete.

In this article I will show you how to use portainer and its GUI to deploy a gitlab container on your setup.

If you use the default setup instructions then your instance will be created on localhost under 9000 port.

docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce

You can access it on http://127.0.0.1:9000/ where you will be prompted to login with the credentials you specified during the initial setup.

Under containers you can create a new container by clicking the add container button

Under volumes you should create a new persistent volume which will be consumed from gitlab for data saving operations.

persistent volume creation for gitlab container

You can either create a new container and specify the dockerHub location or pull the image first and then use it to deploy your instance. I preferred the second way so I pulled the image locally.

docker pull gitlab/gitlab-ce

When completed you should see the below message

From containers press +Add new container. Set up the requested name (gitlab) and specify the image.

According to the documentation three partitions are needed in order to store data for gitlab.

$GITLAB_HOME/data:/var/opt/gitlab
$GITLAB_HOME/logs:/var/log/gitlab
$GITLAB_HOME/config:/etc/gitlab

Under env variables add the needed value as described from Gitlab documentation. Personally I used /Users/username/Documents/Gitlab on my computer.

Press deploy container and the creation procedure should start.

When you first launch your container by checking the logs you will verify that the installation steps are running. This operation should take up to 5-10 minutes.

Then you will see your container running. Stop container and perform also the below configurations:

From restart policies, select always:

From ports configuration add the below bindings (80:80, 443:443)

By mapping ports 80 and 443 to your host you will be able to access gitlab from your browser using localhost:80.

Add also your hostname and domain from network tab.

When the deployment is finished, if you access the localhost address you will see the setup screen.

You can find instructions on how to install gitlab through cli or dockerfile from gitlab

The default username that should be used to login is root.

In order to verify that persistent storage is working as expected, create a new test project, commit a file, close container and then start it again.

Stop container

Login to Gitlab again, and your test-project should be there for you.

Posted on Leave a comment

Combine Windows and Linux inventory hosts on Ansible for Logging purposes

Lets assume you have configured ansible on multiple Windows hosts in order to massively perform patches installation or execute commands. As explained in detail on my previous articles in order to be successful the connection method must be set as winrm (see below)

 ansible_connection = winrm
 ansible_winrm_server_cert_validation = ignore
 ansible_user = administrator
 ansible_password = 
 ansible_become_user = administrator
 ansible_become_method = runas

However if you state this connection method, you cannot connect to linux machines and delegate tasks. One example of this scenario is a windows patching mechanism with wsus and ansible. You can deploy the patches using winrm method but you cannot log output on your localhost as the connection must be changed to ssh.

In order to bypass this problem I added a new group on my inventory for localhost entry for which I specify the connection method and user

[local]
localhost ansible_connection=ssh ansible_become_user=root ansible_become_method=sudo ansible_user=root

Then one will be able to perform a logging action with the below task.

 name: write output to file
   shell: echo "{{ result.stdout }}" >> /root/ansible/something.log
   delegate_to: localhost 

Result is the registered output of the patching procedure.

I am using shell command in order to append a new entry every time I have a result from my previous actions.