<div dir="ltr"><div><div><div><div><div><div><div>Hi All,<br><span>Update on recent work done for the CentOS Container Pipeline.<br><br></span></div><span>-
 We went through building the openshift origin images in Container 
Pipeline and published them to <a href="http://registry.centos.org">registry.centos.org</a> successfully. We 
faced many issues with the upstream dockerfiles and moved to rpm based 
dockerfiles for building the images.<br><br></span></div><span>- We have
 got almost all the monitoring pieces set up in production, now if there
 is any change in the system (i.e. openshift is down, jenkins is not 
communicating, or other changes) we get an alert notifying the change in
 the system.<br><br></span></div><div><span>- We added multiple cron 
jobs for monitoring and communicating with zabix to get notifications on
 changes in system level parameters. <br></span></div><div><span><br></span></div><span>-We
 got test suite set up for pipeline. Now all the images built through 
pipeline, goes through a set of tests for ensuring the container is 
runnable. For now we are testing containers based on CentOS 7.<br><br></span></div><span>-
 We got atomic scan set up. This checks the container for rpm update or 
any other system update required for the container image. For now this 
process only sends notification to the user, stating the changes 
required in container, but does not update the container.<br><br></span></div><span>-
 We noticed that all the source repos do not want the Dockerfile to be 
built for building centos based images. (i.e. for openshift origin we 
built the dockerfiles with name Dockerfile.centos7). To get these type 
of repos built in the pipeline, we added one more parameter 
dockerfile-name to index.yml which allows user to provide name of the 
dockerfile to be built.<br><br></span></div><span>-We saw we are 
bringing up multiple independent stages (like polling source repo, 
build, test, delivery, notification) together to work sequentially as 
well as scale rapidly. Keeping this in mind we came up with beanstalkd 
tubes for managing communication point between all the independent 
phases and synchronizing with necessary information provided through job
 details.<br><br></span></div><span>-We got Atomic Registry built in 
<a href="http://registry.centos.org">registry.centos.org</a> with all its dependent containers available in 
registry.c.o. Even though we got all the dependency containers built in 
<a href="http://registry.co">registry.co</a> atomic registry is pulling origin-deployer and origin-pod 
from <a href="http://docker.io">docker.io</a> as this is hard coded to be pulled from <a href="http://docker.io">docker.io</a>.<br></span><div><div><div><div><div><div><div><div><div><div><br><div><span>Our immediate next focus is :<br></span></div><div><span>- implement firewall rules in production machines.<br></span></div><div><span>- write a wiki page for <a href="http://wiki.centos.org">wiki.centos.org</a> for atomic registry.<br></span></div><div><span>- work on setting up sanity checks for verifying project entries in index.yml <br><br></span></div><div><span>Regards<br></span></div><div><span>Bamacharan Kundu<br></span></div></div></div></div></div></div></div></div></div></div></div><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Bamacharan Kundu<br>IRC Nick- bamachrn<br><a href="http://bamacharankundu.wordpress.com/" target="_blank">http://bamacharankundu.wordpress.com/</a><br></div>
</div>