Terraform, from Ops tool to DevOps with Alien4cloud

Terraform is about simplicity

The success of Terraform in the Ops community is not surprising. Ops can manage easily IaaS resources and their dependencies in a simple file and bring “infra as code” benefits to the company, such as composability, reuse and standardization.

Terraform is also Open-Source and comes with a rich library of reusable and verified modules to ease and accelerate the deployment of infrastructures. So in just a few commands it becomes possible to install and configure complex infrastructures on different clouds providers (Aws, Azure, Google Cloud…) and PaaS (Heroku, Docker Cloud…).

But wait, nowadays terraform is mostly used and managed by Sys Admins/Ops.
This implies that in a majority of cases, when developers or application managers want to deploy an app, they still need to create a request in a ticketing system for the Ops.
Or even train themselves on the tool to provision the infrastructure by themselves, which might be sensitive regarding secrets, usually not shared easily across the organization, and kepts at Ops level.

Can we go further ? Can we bring Terraform to DevOps at the company scale?

From Terraform to Terraform as a service

So Terraform is originally an Ops tool. This is where Alien4cloud comes in to bring Terraform benefits to the different profiles in IT teams across the enterprise.

Alien4cloud is a collaborative platform facilitating DevOps as it allows Dev and Ops to collaborate on the design and deployment of an application.
To design portable applications developers can reuse components, such as Application, Middleware or Infrastructure components. As for Terraform, all theses components are described in a simple file and are reusable to speed up the design phase. To go further with composability, reusability and collaboration, components are stored in the Alien4cloud catalog and developers from different teams can share the components to design the application Blueprint even faster. As a result, the entire application lifecycle is described in a TOSCA blueprint!

Note that TOSCA is a descriptive language. By leveraging TOSCA and the structure it induces, we describe the life cycle of the component and its possible relationships with other components. The implementation must then follow the logic of the description. This implicitly favors best practices and reinforces standardization throughout the organization.

Download our free white paper to learn more about how TOSCA ease DevOps adoption

Now that the blueprint is ready, developers need to deploy the app and nobody wants to wait or to create a ticket. We just want to click deploy. Self- Service deployment is a major challenge of DevOps and Alien4cloud offers a unique solution.

How does it work?

Ops can configure resources up-front for the different infrastructures, Iaas, PaaS, CaaS and can also leverage various configuration tools such as Ansible, Chef, Puppet, Terraform… Each infrastructure resources can be configured independently and precisely thanks to a management system with fine-grained parameters and access rights. This is how Ops are able to provide the resources in self-service for developers to deploy their application in full autonomy, while ensuring security and control.


Terraform for Ops Vs Terraform as self-service


If your Ops teams is already using terraform and the plan is to go DevOps, start with the Alien4cloud open-source version:

Here is an example to provision a Compute and a Security Group on Openstack using Terraform:

Contact us for more information:

White paper: Ease DevOps adoption with TOSCA

If DevOps is sometimes summed up in the collaboration between Devs and Ops,
it is quite another story when it comes to applying it across an organization.

In this free white paper you will learn how to overcome the DevOps challenges with TOSCA:

  • Ease collaboration & governance
  • Provide a Self-Service IT
  • Keep control on infrastructures, resources and services
  • Manage heterogeneous automation practices and tools
  • Manage a bi-modal applications landscape
English or French version

Free download

[contact-form-7 id=”626″ title=”White Paper”]

*By downloading this resource you will also receive our communications and newsletters.

New version A4C 1.4.0, an open-source tool for DevOps

Alien4Cloud is a second generation DevOps platform allowing your existing teams to collaborate on creating and assembling the automation blocks allowing to build and deploy your applications, new or existing, on any infrastructure, Cloud or on-premises, private or public.

We leverage your automation blocks, built on any technology, by orchestrating them through OASIS TOSCA standard.This brings application portability on any infrastructure with no additional cost. We provide a self-service portal as well, allowing Ops to configure roles and accesses on resources and services, and Devs to design applications environments and deploy in full autonomy, leveraging their resources of choice, easing DevOps implementation in enterprises.

Alien4cloud 1.4.0 is an important version and we are proud to deliver it as it brings major improvements with  great new features that bring better reusability, more opening and better operations on existing deployments. Here is an highlight of the main features.

Fine-grained resources management

Alien4cloud 1.4.0 pushes control and security one step further. Ops can now precisely define authorizations independently for each resource at many levels: infrastructure locations, users, user groups, applications, environments… This new setting options on on-demand resources allows a security policy adapted to all situations.

Custom on-demand resources

Admins or Ops can declare and manage custom on-demand resources from the administration panel. It offers an extra layer of security and a complete control that allows your organization to deploy on any cloud, even your custom cloud.

Read more about custom on-demand resources on alien4cloud-blog.com.

Design applications based on services

 Services in alien4cloud refers to any resource that is already running (databases, load balancers, application providing an API etc.) ready to be used by applications through matching of abstract components. From there, the possibilities are endless. Here are some examples of services usage:

  • Design your topology with an abstract database and then match this abstract component with a running database, so you only need to deploy or update the front end.

  • This is also a good way to design complex application infrastructures that will be exposed as services and reused for different projects. Again, reusability is a key factor for a faster delivery. Similarly to on-demand resources, admins and Ops can manage authorizations to control and share services across the enterprise. And of course, it is possible to deploy an application from Alien4cloud to expose it as a service for other teams to use it.

Deploy topologies based on containers / docker

 In 1.4.0, containers scaling capabilities have been added and our kubernetes integration has been significantly improved. To help you get started, we also provide a TOSCA topology to deploy a kubernetes cluster in minutes.  Once the cluster is running, you only need a few clicks are to deploy full docker topologies or even hybrid topologies mixing VMs and containers.

Here is a full use case on video: Hybrid deployments video

 Advanced post deployment update

In alien4cloud 1.4.0, when your app is running, you just have to edit your topology  and click “Update”. The changes will be automatically applied in the running app without having to undeploy.

Hot updates are also particularly useful in a continuous integration context. When a new version of the application code is developed, the developer updates the new artifact without having to undeploy the whole application infrastructure, saving a considerable amount of time.

Improved application versions and variants management

As a best practice, we recommend to use the same topology from dev to production to ensure the continuity throughout the application lifecycle. However, it is preferable in some cases to use different application infrastructure depending on the environment. For example, to develop the application code, you may prefer a light infrastructure with a single compute to run the app. In a QA context you probably want more computes to execute performance tests. Finally, you may prefer secured or adapted components for production.  As a pragmatic solution we introduced the variants concept to support different application infrastructure designs for a same version of an application. It provides more flexibility to optimize deployments time and resources consumption and match your organization needs in terms of development process.

Orchestrator and IaaS support

Alien4Cloud 1.4 supports different orchestrators and infrastructures such as Cloudify 4.0, Amazon Web Services, Azure, VSphere, OpenStack and physical datacenters. Furthermore, Alien4Cloud is customizable to support any resources on any cloud technology of your choice. More information

New getting started

Enough talking, the best way to get it is to try it. Download the open source version and start using alien4cloud to deploy your first application in a few clicks. Here is the step by step guide.

Jetty SSL ciphers and Firefox

When releasing alien4cloud 1.3.0 we upgraded spring boot and jetty (as a spring boot dependency). We recently found that our SSL configuration failed with Firefox while it was working fine under chrome or safari.

The error was quite clear and explained that Firefox wasn’t able to find a valid cipher to communicate with alien4cloud (SSL_ERROR_NO_CYPHER_OVERLAP). Having changed nothing on our side this error was quite unexpected and we had to dive into multiple reading to find out what the issue could be. Hopefully we found some interesting bug reports on mozilla bug tracker first (https://bugzilla.mozilla.org/show_bug.cgi?id=1029179) that explained quite easily while firefox was more restrictive than other browser.

Starting from here we managed to find that our previous version had the ‘TLS_RSA_WITH_AES_256_CBC_SHA’ cipher used by Firefox to communicate with alien4cloud. We also found out that some elliptic curve based ciphers that firefox seems to like more like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 where not working under all of configurations (RHEL OpenJDK 8).

The solution for us was to specify a list of ciphers using spring boot server.ssl.ciphers property and basically to add the TLS_RSA_WITH_AES_256_CBC_SHA cipher that is supported by all browsers.

Have you experienced such issues too ? Do you have preferred resolutions ?