Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £35.99 £24.99. New subscribers only T&Cs apply

Find out more

Home / IT & Computer Science / Cloud Computing / Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline / Environment Configuration

Environment Configuration

.
View transcript
17.1
Now, when we’re configuring standard environments and dealing with infrastructure as code, as well as configuration as code, there’s some things we need to think about. And that’s what our target environment is going to be. There are three very common environments at play, as well as others, I suppose. But infrastructure as a service is a big one. Platform as a service is another, as well as containers. And I want to talk about those three separately, because they are different in the way that we approach both infrastructure as code and configuration as code as well. Let’s start with infrastructure as a service. So with infrastructure as a service, the machines are generally hosted for you.
55.9
Now, this may be in your own data centre or more likely out in a cloud environment. And we might choose those infrastructures or service environments based on our application. Maybe we need access to the underlying infrastructure of some nature. But when we scale this, we’re going to grow it by adding machines on to whatever farm is serving up that application. The key here, though, with infrastructure as a service, we need to have some very sophisticated infrastructure as code and configuration as code tools.
90.4
So for instance, if we want to deploy an entire server farm for our application and make sure that all of the connections are correct, et cetera, we’ll be using something, like Chef, or Puppet, or Ansible, SaltStack, ARM templates, Azure resource manager templates, or other tools that work both in the Cloud and potentially on premises as well to define what those machines look like. And we have to care about those machines at quite a deep level. We need to care about the operating system, the patching, how the ports are opened, et cetera.
123
So in an Ayiaz environment, commonly, you will have scripts that sit outside– inversion control, but outside of the application that work to host that application and to coordinate that infrastructure to host the application. Let’s move from Ayiaz to platform as a service. Now, in platform as a service, we’re working against a hosted platform that kind of defines an infrastructure for us. So for instance, if you’re on the Azure platform, you might deploy to an app service, and that website is you can just deploy the website. All of the scaling and everything is handled for us. Again, you need to determine whether or not your application is supported by a pass environment.
165.3
One of the interesting things, however, is that on a platform as a service environment, generally, the infrastructure as code, as well as the configuration as code, is fairly dramatically simplified into some type of configuration file that often sits with the application itself inversion control. Not necessarily, but very often. Because the app, once we deploy the application and all of its dependencies, we need to define what that looks like. And Platform as a service generally has that baked in to how you spin up an application on that platform, so that’s Platform as a service. And it’s a little bit different than we did as infrastructure as a service.
209.3
Generally, it tends to have a lower barrier to entry, a lower bar, and not as much complexity. Because the tools are baked into the platform itself that are used to scale, and grow, and shrink as necessary, as well as secure and all of the other things that you might configure in that application. Now, let’s take a look at the third, and that third is containers. And containers are predominantly Docker. When we’re talking containers, we’re talking Docker, whether that Docker is running on a Linux machine. Or new coming soon in the Windows world is containerised Windows as well. Both managed by that Docker application. Now, these containers, let’s define them real briefly.
253.4
We can partition our environments in these containers that run on a shared OS, and we can run a lot of containers on one single OS. They tend to be considered much lighter weight than something, like a virtual machine. But when we’re talking the configuration of that machine, we’re talking things, like Docker files, and those sorts of things that help build that container up from scratch. When we’re talking environments, however, now, we want to look across the environment, and we’re looking at other tools, like Docker Swarm or something else, to orchestrate the multiple Docker containers to create that managed environment. Docker Swarm would be one.
295.1
Mesosphere DCOS, Kubernetes, Azure Container Service, these are all tools that help us create that infrastructure as code and configuration as code for a container. Now, in all cases, infrastructure as a service, platform as a service, and containers were looking at wanting to make sure that we have that same configuration, similar environments in dev, test, and production. And that’s why we set up this infrastructure as code and configuration as code. Those three tools that we talked about, a slightly different approach to each of those, but all very important that we have those core fundamentals in our DevOps pipeline.

In the last step, we discussed Infrastructure As Code with Terraform. In this step, we explore environment configuration.

Configuration As Code

Configuration as code, along with Infrastructure as Code, can help you make the management and configuration of your environments automated and consistent.

Configuration as code scripts and environment definitions, when used with tools for managing system configuration, are usually idempotent or can be run multiple times because the scripts or definitions will look for the state of services and install and configure if not running.

Want to keep
learning?

This content is taken from
CloudSwyft Global Systems, Inc. online course,

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

View Course

Idempotence is the property that a deployment command always sets the target environment into the same configuration, regardless of the environment’s starting state. Idempotency is achieved by either automatically configuring an existing target or by discarding the existing target and re-creating a fresh environment.

The following table lists the major differences between manual configuration and configuration as code

In the final step for this activity, we will learn about database as code. Click on Mark as complete to Step off.

Want to keep learning?

This content is taken from CloudSwyft Global Systems, Inc. online course
Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline
View Course
See other articles from this course
This article is from the online course:

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

Created by
Join Now
This article is from the free online

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

Created by
Join Now
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now

Register to receive updates

  • Create an account to receive our newsletter, course recommendations and promotions.

    Register for free