Automated Deployment of LDAP Servers

An Akkodis commercial client organisation in the Lands industry in Australia.

The client asked Akkodis to improve the deployment process related to their LDAP servers and related Amazon Web Services (AWS) Cloud infrastructure. The existing solution relied on Amazon CloudFormation templates to deploy the instances and related elements into each of the four environments (Development, Test, User Acceptance Testing (UAT) and Production

The existing process requires that the related files for the deployments were manually copied into the S3 Buckets and the CloudFormation template run from the user’s desktop.

This posed a risk as a lot of human interactions were required and the risk of the wrong files or the incorrect template being used was high.

The client was keen to move to a Continuous Integration / Continuous Development (CI/CD) approach for their services. As they are using Jenkins, an open-sourced automation server, as one of their options to achieve this, Jenkins was the chosen option for this case.

The client has an existing AWS infrastructure which has been configured with structured Development, Test, UAT and Production environments. Access to these environments is being restricted to only allow access from their secure environments via Single Sign On (SSO) and network related restrictions, all root credentials have been locked off with Multi Factor Authentication (MFA).

As the code repository for the LDAP services was within the client’s AWS CodeCommit service, this allows for the following steps to be created that would support the result Akkodis was looking for.

The client has four separate Jenkins servers, one for each environment. The Development Jenkins server has access to their AWS CodeCommit services and a pipeline task was created within this server to monitor the repository commits and trigger a build process. The Build task extracts the files from the repository and deposit them into an Amazon Simple Storage Services (S3) Bucket. The next task is the “Release”; this copies the files from the build bucket into the release bucket and gets the files ready for deployment.

The final Task in the Development environment is to deploy the release files using a CloudFormation template, with parameters supplied via a build script included in the repository.

The following environments all follow the same process. Subsequent environments only have the “Release” and “Deploy” tasks as theses do not have connection to the AWS CodeCommit repository.

The Release task is set to read from the previous (lower) environments S3 Release Bucket and allow the administrator to select which release they wish to migrate to this environment; once selected the task will copy the files from the lower environment and deposit them into the Release Bucket used for the higher environment, where the release will be available to be used by the Deploy task.

This process means only releases that have been deployed in lower environments can be migrated to the next environment reducing the risk of untested releases making it to production.

The cost impact of this is minimal — an EC2 instance running Jenkins, and the automation is a great time saver for the administration team. As such, its seen as a net TCO improvement.

The project transitioned to be included within the managed services engagement between Akkodis and our client. Akkodis will be carrying on with development of this CI/CD pipeline as part of their BAU support and maintenance.

The lessons learned from the progression of using manual uploading files and AWS CloudFormation templates to create our LDAP environment to using the Jenkins for a CI/CD was a simpler than first assumed: now that Akkodis has completed this process, Akkodis will be looking at moving more of our deployments from manual uploads and CloudFormation templates to using Jenkin to automate these steps.