savishy / devops-experiments Goto Github PK

Some of the issues encountered with Jenkins CLI could be because we used Jenkins CLI as the base image).

eg see commit 2359a19 - I am encountering https://issues.jenkins-ci.org/browse/JENKINS-25858
java.io.IOException: Unexpected termination of the channel.
Observations:

• Using Jenkins CLI to build a job fails when using a Jenkins container.
• However, when Jenkins is locally installed, it worked.

So possibly it could be the way Jenkins is set up in the base image?

Jenkins can be insecure. Need to use OpenSSL on these lines: https://github.com/hughperkins/howto-jenkins-ssl

Ansible playbook needs to reference http://github.com/savishy/ansible-roles for most part instead of reinventing the wheel.

The playbook should also modify EC2 security group.

Etc.

• create and run docker container.
• create and run tomcat container.

It's a wiser approach to do the following

• use a box supported on both aws and virtualbox
• perconajayj/centos64 is one example; there are many others but I chose this because it is small sized (good for my internet connection) and has centos (which is closer to amazon linux).
• when developing the Vagrant/Ansible/Docker recipes, use the virtualbox provider. To test it, use the aws provider.

For #15 I need to start multiple instances. Need to modify Vagrantfile appropriately.

In #5 two containers are created on the host.
The tomcat container does not contain a WAR of the application initially - it is just a stub application.

Need to figure out a way (e.g. using jenkins-cli.jar) to trigger a first run of the Jenkins job.

• This will build a WAR;
• Then deploy the WAR to the Tomcat Docker container.

The v0.2 tag needs to be reproduced with Chef as well instead of Ansible.

To make things easily changeable (e.g. changing ports, usernames, folder locations etc) the Dockerfiles should be ansible-managed.

Vagrantfile + AWS Configuration + Invocation of Ansible Playbook. This part was done before but needs reverification.

While working on #10 I am encountering the following issue

• to be able to docker push, a credentials is needed to be pre-stored in the jenkins container.
• I created a set of credentials (for docker hub) in Jenkins in the credentials module.
• this output a credentials.xml in JENKINS_HOME, which I then extracted.
• I am pushing this credentials XML into JENKINS_HOME while building the Jenkins image
• However, it seems the same encoding is not used everytime so the credentials.xml is not valid across Jenkins installations.
• i.e pulling this from one running Jenkins instance, then pushing it into a different instance does not seem to work.

As a result, docker push does not work unless you manually edit the credentials through UI before docker-pushing .

Notes:

• have tried using jenkins-cli. Could not figure out (despite trying for hours) how to use create-credentials-by-xml.
• have tried using the docker remote API call as well (curl -X POST /images/name/push). Encountering weird login issue."
  [attempt-2 053aca1] #10 encountering issue #11 - to be able to docker push, a credentials is needed to be pre-stored in the jenkins container. - I created a set of credentials (for docker hub) in Jenkins in the credentials module. - this output a credentials.xml in JENKINS_HOME, which I then extracted. - I am pushing this credentials XML into JENKINS_HOME while building the Jenkins image - However, it seems the same encoding is not used everytime so the credentials.xml is not valid across Jenkins installations. - i.e pulling this from one running Jenkins instance, then pushing it into a different instance does not seem to work.

Instead of deploying the built WAR file as a post-build step, the Jenkins job should create a selfcontained image (tomcat + WAR) and push it to Docker Hub.

The playbook for tomcat should then pull from Docker Hub.

As the Docker image is created, we need to package monitoring capabilities into it.

This will involve a monitoring instance (maybe built with the ELK or EFK stack). The docker image should be configured to push logs etc to it so that we get metrics on uptime, I/O and throughput.

• Jobs managed with Jenkins Pipeline