viernes, enero 27, 2023
InicioHealthCisco Cloud Native Safety - Half 2, Provisioning the Infrastructure

Cisco Cloud Native Safety – Half 2, Provisioning the Infrastructure

[ad_1]

In half 1 of this weblog collection, we overviewed the totally different instruments  that will be used as you go up the stack from infrastructure to software. On this weblog, we can be provisioning our Infrastructure as Code (IaC) utilizing Terraform, Ansible, Jenkins and GitHub. First, we’ll arrange our growth setting with all of the instruments wanted for this deployment. Then we’ll evaluate our Terraform configuration recordsdata and Ansible playbooks intimately.

As all the time, your growth setting might differ from what’s getting used on this collection, however all of the Dev instruments we can be utilizing can be found on Microsoft, Mac, and Linux working programs. In our case, we can be utilizing Ubuntu 20.04 to run all our DevOps instruments.

We are going to deploy the most recent variations of Terraform, Ansible, AWS CLI, Docker, Jenkins and kubectl on our DevBox. Then we create a GitHub repository for supply code administration and model management of our infrastructure. We can be utilizing the Cloud Native Safety SPOT-ON Collection repository on this collection. The very first thing we’re going to do is create a function department known as infra. We’re going to use function branches to merge our code into the important department, which is our manufacturing department. When adjustments are made to the important department, the construct can be triggered by Jenkins. For every SPOT-On episode that we create, there can be a function department related to it. For instance, within the subsequent episode we’ll deploy our functions, so we’ll create one other function department named apps and merge into important.

Cloud native security

Video demo for “Establishing the Dev Surroundings”

Within the subsequent part we may have an in depth have a look at the set up. I’ve additionally created a demo video for these of you preferring to observe as an alternative of learn. For individuals who choose my detailed written directions, you’ll discover them beneath. Additionally, don’t fear, this isn’t the final episode within the collection! Subsequent up, we’ll use GitOps and CI/CD to construct and deploy the cloud infrastructure. For now, right here’s my demo video for this Half 2:

Cisco Safe Cloud Native Safety – Half 2.1 – Establishing the Dev Surroundings

Detailed Directions

In case you are studying this, it means you have an interest to study the small print of this arrange. Let’s soar proper in! First, allow us to have a look at Jenkins. We are going to create a multibranch pipeline named Spot On. We are going to use the Cloud Native Safety SPOT ON Collection as our Department Supply and can uncover all branches.

Secure Cloud Native

The Construct Configuration can be outlined by the Jenkinsfile. The Jenkinsfile is the directions of the pipeline itself. We are going to dive deeper into the Jenkinsfile within the subsequent part.

Secure Cloud Native

Once we save the pipeline job, Jenkins will scan the GitHub repository and discover the branches we created. When a construct is run it would pull down the code from this repository.

Secure Cloud Native

Now that we have now our pipeline built-in with our supply code repository, allow us to have a look at the infrastructure as code. Wanting on the construction of our infra department we see a Jenkinsfile, which is our Pipeline as Code. We additionally see Terraform recordsdata important.tf, output.tf, and variables.tf. These Terraform configuration recordsdata are set on the root of the challenge, known as the Root Module. There may be additionally a modules/infra listing which additionally has a bunch of Terraform recordsdata. This module listing accommodates the code that can provision the infrastructure.

Secure Cloud Native

Like we mentioned beforehand, the Jenkinsfile is our Pipeline as Code and offers all of the directions for constructing our pipeline. Wanting on the Jenkinsfile first we outline the pipeline brokers. On this case we’re simply utilizing the Jenkins grasp, however we might have an outlined agent for every stage if we want. Subsequent, we set the setting variables. Right here we set the setting title and ID, the AWS entry and secret keys, in addition to the area, availability zones, SSH key and FTD credentials.

Secure Cloud Native

As you may see a few of these variables are outlined right here on the Jenkinsfile, however a few of the variables are referencing the syntax credentials(). Jenkins’ declarative Pipeline makes use of this helper methodology which helps secret textual content, username, and password, in addition to secret file credentials. We set these variables in Jenkins on the Handle Jenkins > Handle Credentials web page. This fashion we are able to go these secret variables to Terraform securely.

Secure Cloud Native

The subsequent part of the Jenkinsfile is the place our phases are outlined. For proper now, we solely have one stage which is Construct Surroundings. Inside every stage we have now a number of steps. Step one is simply echoing Constructing Surroundings on the construct output. The second step can be a terraform get –replace, which is used to replace any new Terraform suppliers added to the challenge. The third step will initialize all of the suppliers configured within the challenge. The fourth step will apply the Terraform configuration passing all of the variables wanted to provision the setting.

Secure Cloud Native

Allow us to have a look at the Terraform configuration recordsdata. The primary file to dive into is important.tf. This file is ready on the root of the challenge, that means it’s within the root module. On this file we outline one other module named Infrastructure which is sourced from ./modules/infra. You possibly can consider a module as a perform in different programming languages. On this case we create a module to deploy our infrastructure and go the mandatory setting variables to this module. Why would we do that? For instance, let’s say we have now a number of environments, reminiscent of Dev, Take a look at, QA, and Prod. We would like the deploy every setting with the identical actual sources, however the setting variables reminiscent of IP addresses, subnets, areas, and zones needs to be totally different. We additionally set our Terraform Suppliers right here in important.tf.

Secure Cloud Native

There may be additionally a variables.tf file situated within the root module. These are the identical variables we’re passing from Jenkins as proven above, we’re simply declaring them in Terraform.

Then we have now the modules/infra listing which is the place the infrastructure module config recordsdata are situated. On this listing we see one other important.tf and variables.tf recordsdata. This will likely appear redundant however consider this like how we set world variables and native variables in different programming languages. On this case we’re defining variables within the root module and passing them to the infra module, which might be the identical as declaring variables globally and passing them variables as arguments to the perform.

There are additionally configuration recordsdata for the vpc.tf, ftdv.tf, and eks.tf. Every one among these recordsdata provisions their respective configurations. We might put all these configurations into one file however breaking it up makes it simpler to learn and extra modular. There may be additionally a file named ftdv_ansible_deploy.tf. We use this Terraform configuration file to run our Ansible playbooks in a Docker container. These Ansible playbooks are used to configure the Safe Firewall coverage we have now deployed on one among our EC2 cases.

Secure Cloud Native    Secure Cloud Native

Keep tuned

Within the subsequent episode of this collection, we’ll use GitOps and CI/CD to construct and deploy the cloud infrastructure. Hope to see you again once more!

Please let me know when you have any questions, both within the “feedback” part beneath, or through the GitHub points.

 


We’d love to listen to what you assume. Ask a query or depart a remark beneath.
And keep linked with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Fb Developer Video Channel

 

Share:



[ad_2]

RELATED ARTICLES

DEJA UNA RESPUESTA

Por favor ingrese su comentario!
Por favor ingrese su nombre aquí