Management of AWS multi-environment resources

1. JENKINS+TERRAGRUNT
+TERRAFORM
ECOSYSTEM
Management of AWS multi-environment resources.

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).

5. Target audience
5

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

9. Introducing: IDT Terra Live
9

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.

11. Organize IDT Terra-Live ecosystem
11

12. Import Existing Core Resources
12

13. Access Core Resources
13

14. Default loader for each terraform stack
14

15. Variables/outputs extension
15

16. Terra Live repository structure
16

17. Process terragrunt stack
17

18. Architecture diagram

19. Terra Live Pull Request processing
19

20. Terra Live Push processing
20

21. Comparison with native terraform
Terra Live Native Terraform CloudFormation
UI support + +-
modules.tf
+-
CloudFormation
Designer
Company policies
integration + - -
GitFlow-like
interaction + +-
Terraform Cloud
-

22. Future plans
22

23. 23
THANKS!
Any questions?
You can find me at alexander.dobrodey@idt.net