New level of automation with Ansible

Ansible is a simple agent-less automation tool that has changed the world for the better. It has many use cases and wide adoption (used by many upstream projects like Kubernetes and there are thousands of rules submitted to Ansible Galaxy). In this article, we are going to demonstrate Ansible. The intention of this article is not to teach you the basics of Ansible, but to motivate you to learn it.

Continue reading “New level of automation with Ansible”

Share

Automate integration CI/CD process

Red Hat Fuse Integration Service 2.0 tech preview was released a few weeks ago and as it’s based on Red Hat OpenShift 3.3, which has pipeline capability on top of it (tech preview on OpenShift as well), you are able to get one step closer to a more automated and agile continuous integration. As well as, a deployment one-stop platform for us, the integration developer.

Continue reading Automate integration CI/CD process

Share

Using the Kubernetes Client for Go

The Kubernetes client package for Go provides developers with a vast range of functions to access data and resources in a cluster. Taking advantage of its capabilities can allow the opportunity to build powerful controllers, monitoring and managing your cluster, beyond the scope of what is offered by stock OpenShift or Kubernetes setups.

For example, the PodInterface allows you to list, update, delete, or get specific pods either by namespace or across all namespaces. This interface is complemented by similar implementations for many other cluster resource types such as ReplicationControllers and ResourceQuotas.

Continue reading “Using the Kubernetes Client for Go”

Share

Automating microservices deployment with Ansible

One of the main principles of microservices is to be independently deployable. As a consequence, Microservices development and operation tend to be much more complex than a Monolith because of their distributed nature — if your IT team has not moved out yet from its silos and has adopted DevOps practices, the operations team will not really understand why they have to deploy hundreds of independent software pieces in opposite to the “good old monolith”.

“You need a mature operations team to manage lots of services, which are being redeployed regularly”  (Microservices trade-offs by Martin Fowler).

The operations team and the software development team should work together adopting DevOps practices to avoid silos and deployment process where the software team throws the software over the wall.

Screenshot 2016-11-18 13.46.37.png

Ideally, each Microservices team is multifunctional and own the software artifact from conception to production. Given the multifunctional nature of these teams, “infrastructure as code (IaC)” and automation are now a necessity. DevOps teams share the knowledge of server provisioning, configuration management and deployment. There are several tools and approaches for IaC. As an example, I can mention Kubernetes, that allows you to define its objects as yaml or json files.

screenshot-2016-11-16-10-53-00

A couple months ago, I published a blog post that shows how to have your own (no-cost) microservices playground.  The focus of this material is educational. It provides instructions on how to deploy each microservice independently. However, some people would like to see all of them running running in few minutes.

To show how you can run this microservices playground environment in less than 20 minutes, I decided to record the following screencast that shows how to create an OpenShift cluster using “oc cluster up” (Check out “Four creative ways to create an OpenShift/Kubernetes dev environment“), and deploy all of them using Ansible.

Continue reading “Automating microservices deployment with Ansible”

Share

Container Orchestration Specification for better DevOps

The world is moving to microservices, where applications are composed of a complex topology of components, orchestrated into a coordinated topology.

Microservices have become increasingly popular as they increase business agility and reduce the time for changes to be made. On top of this, containers make it easier for organizations to adopt microservices.

Increasingly, containers are the runtimes used for composition, and many excellent solutions have been developed to handle container orchestration such as: Kubernetes/OpenShift; Mesos and its many frameworks like Marathon; and even Docker Compose, Swarm and SwarmKit are trying to address these issues.

But at what cost?

We’ve all experienced that moment when we’ve been working long hours and think “yes, that feature is ready to ship”. We release it into our staging environment and bang, nothing works, and we don’t really know why. What if you could consistently take the same topology you ran in your development workspace, and run it in other, enterprise grade, environments such as your staging or production, and expect it to always JUST WORK?

Continue reading “Container Orchestration Specification for better DevOps”

Share