2. About me
Software Engineer with over 8 years of IT experience in
system administration treating infrastructure as code
adhering to DevOps cultural aspects.
In-depth programming experiences with Python, Groovy,
SQL, Java and JavaScript.
Proficiency with client/server architecture and
administration, including cloud infrastructure, experienced
in supporting server/application life cycles, upgrading
productive systems/databases.
Hello,
I am Alexander Dobrodey!
3. Overview
▸ Is it possible to help an average developer or QA
engineer to successfully implement Infrastructure
as Code for his projects/solutions.
▸ How to use its principles without learning how to
write terraform/chef/ansible code by yourself?
▸ How to apply company policies and business
requirements to each resource created in the
cloud?
4. Understanding the problems
01
Most developers and QA engineers don’t know best-
practices of configuration and utilization of AWS
resources.
02
Company owns multiple services created at different
times. Some of them were created more than 20 years
ago and require support for existing architecture.
03
Company aims on cost reduction, faster development
and deployment, removing risks and security
violations(human errors).
6. DevOps Engineer
▸ Describe Amazon Services as generic
terraform modules.
▸ Apply Company standards and policies
(cost-allocation tags, security constraints)
▸ Import existing resources into
Infrastructure as Code.
6
7. Software/QA Engineers
▸ Rapidly create Dev/QA/UAT environments
with full control of the process
▸ Clearly perceive impact of proposed
changes for their environment.
▸ Update infrastructure in flow similar to
development of application logic.
7
8. Release Managers/Product Owners
▸ Recognize impact of proposed changes
for production environment.
▸ Approve/reject modification of
production environment.
▸ Reduce Time to Market.
8
10. Terminology
Core Services
account
AWS account managed by
DevOps team with main IAM role
for terraform multi-environment
provisioning..
Managed accounts
AWS accounts for different
environments where user’s
services are expected to run.
Terraform stacks
Terraform modules with added
business logic and company
policies validation. Are available
for user’s terra-live repositories
for consumption.
10
Terra Live
repositories
User’s self-service repositories,
containing terragrunt files,
describing environments and
processed via Jenkins.
Implement GitOps.
Terraform modules
repositories
Repositories with terraform
stacks, where users can
contribute new IaC logic.
Terra Live
environments
Described via terragrunt set of
terraform stacks expected to be
applied on specific AWS
account/region/VPC.
Is it possible to help average developer or QA engineer successfully implement it for his projects/solutions. How to use its principles without learning how to write terraform/chef/ansible code by yourself? How to apply company policies and business requirements on each resource created in the cloud?
Solution that simplifies user interaction with the AWS cloud. IDT Terra Live is an eco-system of Jenkins+Terragrunt+Terraform where users can easily deploy and maintain their services and be sure that they won’t violate existing policies. Balans of control and flexibility achieved.
Terragrunt logic is included in default terragrunt.tfvars which loads global tags, environment configuration (mapping of environment name on AWS account, region, VPC). It is processed with path to the Terraform stack and generated terraform.tfvars to create resources in AWS cloud.
On Pull Request to terra-live repository master Jenkins will process web-hook, validate setup, compare source HEAD with master branch and prepare plan on modification of all stacks in environment.
On Push to terra-live repository master Jenkins will process web-hook, validate setup, compare source HEAD with last success apply on master branch, prepare plan for additional approval and then apply changes. At the end it will send resulting outputs as commit comment