[CentOS-devel] Curating containers

Bamacharan Kundu

bamachrn at gmail.com
Wed Feb 10 11:47:50 UTC 2016


On Wed, Feb 10, 2016 at 4:30 PM, Karanbir Singh <kbsingh at centos.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/02/16 07:29, Bamacharan Kundu wrote:
> > Hi,
> >
> > Vaclav presented the build pipeline very nicely and this would
> > take out lot of tension for building the code, checking the code
> > standards and test cases from the developer.
> >
> > I would like to add few points on this.
> >
> > On Tue, Feb 9, 2016 at 8:08 PM, Vaclav Pavlin <vpavlin at redhat.com
> > <mailto:vpavlin at redhat.com>> wrote:
> >
> >
> > Hi all,
> >
> > As KB wrote, I brought up the idea of using OpenShift as a glue
> > (i.e. workflow controller). The result can be found here:
> >
> > https://github.com/vpavlin/cccp-demo-openshift
> >
> > TL;DR:
> >
> > The repository contains OpenShift Template defining the workflow -
> > build,test, delivery and (very poorly) implements the steps through
> > Docker images (i.e. Dockerfiles and run scripts).
> >
> > The developer should do only git push to his VCS and this should
> > trigger the build process in the pipeline.
>
> in an onprem story that would map well, but note that were aiming to
> run a hosted service with a distinct UI ( even if the UI is no UI )
>

Yes, now I got it. I had a thought to minimize the number of Dockerfiles,
so that the user does not get confused of.

>
> >
> > In this TDD process all the environments (including the build,
> > test, delivery) would be created as a container and once the step
> > is over it will destroy the environment. As output this will
> > generate a application runtime along with the successfully built
> > application code to registry.
> >
> > As you mentioned this would be tagged with test along with jenkins
> > build id, so that developer or QA can trace for which commit this
> > is built.
> >
> > Then for the next stages, successfully built image would be
> > deployed to openshift instance to get through the test, delivery
> > stages checking, along with the quality gates.
> >
> > all the stages should be linked to pipeline and should be easily
> > re-producible so that any one can check or regenerate the issues
> > instantly.
>
> add another dimension there - collection of related containers, ie.
> the entire microservice should be reproduceable.
>
> This means system needs to maintain all the linking and volume sharing
of the components.

> >
> > It's easily runnable in Vagrant with use of Project Atomic
> > Developer Bundle.
> >
> > If you are interested in more info, I'd suggest to read the readme
> > in the repo, I hope it summarizes it clearly.
> >
> > It's a very minimal demo, but I think it suggests the path, which
> > could take us to the Unicorns land, quite well:).
> >
> > Let me know in case of any questions, suggestions or requests for
> > guidance in case anybody decides to take this further.
> >
> > I would like to take this further, please let me know if my
> > thought process is in the same line as yours or any changes,
> > suggestions.
>
> we need to work through whats needed to now integrate with the
> cccp-index content, and then map that back to deliverables. I had
> asked Zeeshan to look at registry side for delivery space, unsure how
> far he's gotten with that.


I believe, I should look for integration with cccp-index content?

Regards
Bamacharan

-- 
Bamacharan Kundu
IRC Nick- bamachrn
http://bamacharankundu.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20160210/7cc5ff17/attachment-0004.html>


More information about the CentOS-devel mailing list