Changes of Dockery 0.3.0

Huh! Finally Dockery version 0.3.0 is ready to get released and I already published the hosted version. The Chrome update scheduled to this week. It took some time release a new version, because of my holidays and flu, but the real reason was the scope of the release was too big.

Because of the efficient mixture of my ego and terrible estimation skills :)

Let's see what's changed and why:

• search for container diff - the simple paging is not so efficient, I had to go through long list of changes sometimes to find what I'm looking for.
• commit container as image - initial version, I don't know this feature how often used. Personally I prefer creating Dockerfiles. It will be improved with some extra features (Dockerfile statement filtering, etc.)
• extending saved configuration data - from now some extra stuff will be saved too. I'd like to implement to reenter to the last state of the app at the next run. 
• bootstrapping page - a nice eye-candy to hide angular placeholders during the app loading :)
• login into the docker hub - to push docker image (will be implemented in 0.3.1) back to a repo we need to login 
• cosmetics - removed $promise from json data, added some details how to setup CORS for docker daemon

!!4! Announcing the hosted app!!44!

This is the very point of this release. In the past I invested reasonable efforts] to make the chrome packaged app more user friendly, but I had hard times to find the documentation for anything what I planned to add, to enable or reimplement because of the security settings. 

Finally I decided to switch to the hosted app model to provide more user friendly UI interaction and faster development of new features.
In case of high demand to the dedicated version, I surely consider to re-release it (the customer is the king), but at the moment I'm believing in the hosted version is much better for the users.

Link: dockery

Using Docker for microservice development

Intro

Before we begin, I'd like to clarify: this is not a Yet Another Basic Docker Tutorial. If you need one, just go to the Docker site or use Google as a rich resource of tutorial links. I used the official site to learn it, but these days a lot of talented colleagues made great tutorials. Also you could get a good overview about what is Docker.

The purpose of this post to make a short introduction about Docker as application platform and microservice runtime environment as a starter of the upcoming blog posts.

The microservice architecture is coming closer every day to us and getting recognized not just by some hot startups and innovative companies, but the mature organizations too. We are still learning how to use their benefits as scalability, simpler maintenance and structure. We are also experiencing the increased costs of  microservices as paradigm shift from SOA, orchestration, duplication, increased skill demand on several areas and so on. 

Hosted version of Dockery is available at http://dockery.io/dockery

I totally forgot to release Dockery as hosted web application for simpler access, but from now these days are over. Dockery is available on the dockery.io domain under the link: http://dockery.io/dockery/. Bookmark it quickly and manage your Docker hosts easily with the app.
I believe this is the easiest way to access recent version of Dockery from anywhere, but don't forget: this version is always in beta state :)

Dockery added to the official Docker documentation as client library

I'm proudly announcing: my simple Docker management application Dockery is added to the official Docker documentation as remote api client library. It started as a pet project to learn some Angular basics as a notorious backend developer, but somehow it turned to a fun and my colleague Jens Wlodarczyk convinced me to take it more seriously and popped up the idea to create a Chrome app version too. That wasn't easy for a novice javascript learner, but now it used by other guys around the Earth and I'm getting feedback about what to improve/fix. This is my very first travel into the open source community and I think this is a great source of motivation and gives me extra energy to work on it. The blog of course will focus on different things, but this is a great achievment for me and I'm moved a bit now. Sniffsniffsniff... :)

Pull request build automation for Stash with Jenkins

Intro

Moving toward the frequent releasing is a challenging goal for all organizations. It needs well crafted delivery pipelines, devops mindset to take care about the whole software delivery lifecycle and also needs efficient tooling and methodology from the beginning. The starting point is the definition of a supportive workflow for your SCM. We are using Atlassian Stash as Git server, therefore I looked after for Git based workflows. Click on the links for the detailed description of these workflows, the Atlassian guys made a great job to explain them.

Jenkins DSL scripting - Part 4 - adding our own library to the DSL plugin /TL;DR/

Intro

This is actually the last part of my series about Jenkins DSL scripting. I already discussed the basics with environment setup, job creation and linking, view definition and the importance of the easily reproducible build pipelines with non-pet Jenkins servers. The following part I explained some more advanced topics, like the interaction with the environment, credentials and the customization options with configure block

In this part I'm talking about how to extend the plugin's functionality with your own commands and implement complex logic behind it.

I'd like to say a REALLY big thank you to my colleague Thomas Schneider for his approval to reuse his code snippets and findings in this blogpost. Respect!

Jenkins DSL scripting - Part 3 - intermediate /TL;DR/

This is the third article in my series about the journey of Jenkins DSL scripting.
In the first part we learned the basics of the DSL plugin features with detailed explanation of the building blocks to enable you to create simple pipelines.

The second part described the side effects of dynamic pipeline creation, the role of seed/boostrap job and finally demonstrated and described a simple pipeline project for an application. They were the basic part of DSL scripting and focuses on the pipeline as a whole.

Now we are entering to the intermediate level and focusing on particular problems of the pipeline creation like passing values via environment variables, using credentials to access protected resources, extending the DSL plugin functionality with the configure block to use non-covered plugin functions and so on. 

Jenkins DSL scripting - Part 2 - environment setup /TL;DR/

In my first article I wrote about the basics of the Jenkins DSL scripting. I explained my motivation to switch from static Jenkins configuration to a more dynamic one and tried to show the benefits via small examples.

In this part I'm talking about some interesting side effects of dynamic pipeline generation, the role of seed jobs, my development setup and finally I define a basic pipeline as a blueprint for other's project. I hope this entry will be shorter then the first one :)

Jenkins DSL scripting - Part 1 - basics /TL;DR/

As the Continuous Delivery is spreading, more and more CI servers are working on daily builds, tests and releases. With the growth of the companies' codebase we are repeating almost the same steps with slight changes to implement CI/CD coverage for the new modules and projects, but the maintenance or update of these steps is getting harder. In a monolithic environment the growth is not so remarkable, but as we are moving toward the microservice paradigm with containerization, the maintenance effort of these configurations could jump quickly.

The majority of the servers I saw was run the same sequence of checkout, build, package, deploy, tests steps and finally marked artifact as releasable or released it into the production environment.

Also all of these servers were guarded by intensively and only some chosen ones were able to change configs or could consider to upgrade to a more recent version with shaky hands and unpredictable compatibility issues. We could agree on the high importance of these servers and their unique role, but how could we mitigate the risk and dependency on these servers? How could we repeat pipeline assembling steps in a reliable way and make predictable the outcome?

Purpose of this document

This is the first part of the series of tutorials about Jenkins scripting to achieve a fully automated, decentralized and replaceable delivery pipeline architecture with better flexibility than the monolithic, centralized Jenkins setup. In the series I’m talking about the scripting basics (here), some intermediate steps (xml configuration, modularization, common tasks, DslFactory, etc.) and the extension of the plugin function with own library routines. In this part I’m explaining only the basics of job and view creation, the syntax and a basic pipeline generation with some recommendations.

Dockery Light released as Chrome app

I recently released the beta version of my Docker management application Dockery Light (I'm still working on the name/branding hehe). The app is quite beta, but able to help you as developer to manage docker hosts via the remote api. 

All feedbacks, bug reports, critics, enhancement ideas are warmly welcome :)

You can add to your Chrome browser via this link.

Feel free to fork it and send pull requests: Github repository 

Few words about docker volumes

Docker volumes | Create infographics