Juju has now a Drupal Charm

On August 1st, 2014, folks at Canonical (company responsible for Ubuntu and which promotes free software with employees in more than 30 countries) hosted a hangout on air with some of Taller guys in order to receive feedback about Juju. The invitation to this conversation arose because we are one of the first companies to adopt Juju to work in the local environment and, because of that, we can identify improvements.

This is a tool that no one knew how to use and we were the early adopters; we are one of the only ones with the ability to provide them this kind of feedback.

To understand better the importance of this moment, our relationship with Canonical and how exciting it was, we will contextualize.

One of the major problems that may be related to deploy is the divergence of environment configuration. Difficulties begin just when we are already at the production environment, because it’s too much work to replicate it and also to build the same environment / topology only for testing, given they’re complex topologies and several softwares and machines are involved. We consider this one of the greatest benefits of using Juju: to solve the repetitive and mechanical work .

Based on that we, at Taller, started thinking about how to create a system to solve this type of difficulty. We started the architecture of a service-oriented system, where the use of “types of relations” between services facilitates the arrangement of a topology. But before that, we did a research to look for something that would meet those needs, and that’s when we found Juju.

Juju is, briefly, an automatisation tool for your cloud infrastructure. Our first contact was through another tool, Docker, that is a mechanism for managing Linux Containers (LXC) and, based on it, we thought about how we could create a tool to orchestrate an environment and the different topology types.

[UPDATE]: I’m gonna talk about Juju at the DrupalCon Latin America 2015 in the session “DevOps, where to start?” and later in an awesome Code Sprint of the Drupal charm.

Juju in practice

This tool is currently under development and beta phase. The biggest instability is using it in the development environment. As we started studying and using Juju, we noticed that a charm for Drupal didn’t exist, so no way to install and configure it, the service wasn’t ready and optimized for enterprise with all the experiences and the know-how that we’re habituated. Faced with this context, we decided to developed it.

And then, Drupal charm’s development started, enterprise-ready. As Juju was tested, we made the charm in Bash, and once it worked, we chose to employ a tool that facilitates its management configuration and service setup. Among the options we found, Puppet, Chef, Saltstack and Ansible were analyzed, we opted for the last one because it’s simpler, understandable and has a small learning curve. The result of this experiment is the charm for Drupal in Ansible.

The responsible team for Juju at Canonical with whom we had already been communicating via IRC, supported us during this journey. We informed them that we needed to talk about some problems, possible solutions and more suggestions for improvement.

At this point, we scheduled an hangout that included the participation of Taller Team represented by me, Handrus and Renato (those who are already working with Juju locally) and the team Canonical represented by Jorge Castro, Antonio Rosales, and José Antonio Rey from the Ubuntu community.

During the hangout, a document was created so all the suggestions were recorded. This document is still being built considering the new definitions that have been made.

Continuous Improvement

More than just a conversation between companies, that was a moment to clear the vision that this is one of the tools that aligns itself to DevOps culture, so we can automate the processes of deploy, configuration and topology setup and still ensure quality and reduction of waste. This gives us opportunity to focus on what really matters: creating innovative solutions.

Our friends at Canonical received our suggestions and feedback very well, and some of them will be adressed in the next Juju sprints. This scenario only reinforces the potential of collective creation, having a community collaborating and participating in the construction of a technology. We don’t want to simply use something, we want to be an active part of the design and execution of these transforming tools. And that’s why we were so excited to participate in this particular process and with all the attention received.

Access the recorded video of the hangout: