Python SDK: Why Give a Fish When We Can Give a Fishing Rod

By Ganna Shargorodska


Recently we wrote about the method of using Packer with EPAM Cloud developed by our colleagues from St. Petersburg. They created a plugin using Orchestrator API methods to automate custom image creation. The article also mentioned that it was not the only initiative where EPAM Cloud methods are adapted for use in other tools. Indeed, almost at the same time the colleagues working on the DEP Infrastructure Platform approached the Cloud team for ideas of using Orchestrator in their solutions. A small request quickly grew into a side project which the rest of EPAM may appreciate. But let's start from the beginning.

In short, the DEP team creates tools for automated infrastructure deployment to save time and effort for starting a complex environment with several platforms. You can read about the DEP project in more detail here.

They use Ansible as their tool of automated provisioning and Molecule for testing various Ansible roles using Ansible playbooks. One of the challenges was automating infrastructure deployment on different providers - private cloud, AWS, Microsoft Azure. This meant writing a different playbook for each provider to test it properly. But wait... there is EPAM Cloud boasting its hybridization possibilities. There is no need to adapt playbooks to different cloud providers when one can have just one for EPAM Cloud and use its native integration mechanisms. Deploy instances in EPAM Cloud and see how they perform. Then change the region to AWS and see the same instances but deployed in Amazon. Same with Azure or Google Cloud. Just like that.

This is when Ihar Barysevich and Aliaksandr Kharkevich from DEP came to the Cloud team looking for Orchestrator API methods. There is a Maestro Java SDK publicly posted on the EPAM artifactory, but Java SDK did not help much in their case. The DEP Infrastructure Platform is DevOps-facing, and DevOps tend to use Python rather than Java. And there was no Python SDK for Orchestrator, and had never been.

So Ihar and Aliaksandr got together with Maksym Zinkevych and Serhii Solohub from the EPAM Cloud team to create several Python methods which the DEP project needed. The idea snowballed into an ambitious initiative of putting together a complete Python SDK covering the whole Orchestrator functionality. There are many automation activities in EPAM Systems, and who knows which of the Orchestrator functionality may be needed.

To cut a long story short, EPAM Orchestrator 2.1.96 came out with the first version of Python SDK which you can find in the repository. The first version is based on the scope suggested by the guys from the DEP initiative, and includes the most important infrastructure management functions as well as integration with Ansible to support the automation flows developed by DEP:

  • - Authorization (basic Orchestrator authorization and access to AWS/Azure/Google Management Console)
  • - Instance management
  • - Properties and tags management
  • - Ansible service management
  • - Instance ownership and related functions (permissions, scope of access, etc.)

We will continue adding methods to form a complete SDK. Please try it and do give feedback, for this is the surest way for us to know if everything is working as it should.