[MUSIC]
>> How's it going guys?
What is up?
Welcome to another exciting episode of moving to the Cloud.
Fun stuff, guys. We got a lot of stuff on the agenda today.
As I told you guys, I'm not just trying to build something
super Microsoft-centric or Azure-centric or anything like that.
What I'm trying to do is I'm trying to build
the best solution for what I need.
One of the things I wanted to do is
I wanted to work with Terraform Cloud.
Check it out.
Here's essentially what I have done.
Last time we were streaming,
we set up Azure DevOps,
and then that works with their pipelines.
One of the things I took away from this right away
was how do I want to set this up?
I'm going to diagram how automation
in just a design flow is going to look like.
First and foremost, what we're going to do is
we're going take one of these guys here
and we're going to say that this is the ALT F4 LLC Project.
This is the ALT F4 LLC DevOps Project.
That's what we'll call it.
Now, these are two separate projects and inside of them,
if we just do this a little bit more,
all of this lives in the Quirk DevOps Project.
Now, the first thing we have to think about
is we're in a chicken before the egg situation here.
If we want all of the quirk stuff to be in the quirk projects,
you got to put that code somewhere else.
The real thing is that if we create a higher level organization,
if we do that, then we say,
well, everything related to the company,
all of that quirk really shouldn't care about at all.
As a matter of fact,
if quirk was ever to become a real product,
then I would have a DevOps Team at ALT F4
that would then be reached out to by the quirk product team.
Then the quirk product team would say,
"Hey, we need this."
That's the job of the DevOps engineers.
This allows us to also create a really interesting flow,
which is now what we're doing is we're saying,
we'll have a quirk product, a developer,
if they wanted to, could go into this repo
and add resources that they needed to.
But a developer could not go into this repo,
which manages these
and do anything malicious or anything like that,
essentially just because at the end of the day,
we have completely separated that permission.
That is basically what I set up.
Now that we have that,
let's go ahead and actually look at this Terraform code.
This is already set up,
but the main thing to note here is that
I have essentially all the repositories I need now to work with.
I should actually only have one repo in here,
and yeah, here it is.
Here's all of the Terraform that I just showed you.
One more thing.
Let me go ahead and actually show you one other thing.
Like I said, we have ALT F4 LLC with its own Terraform automation,
and we have quirk with its own Terraform automation.
If I go into quirk and I go into repos,
and you can see here,
it's already wired up with Azure,
it's already wired up with Terraform IO
or basically Terraform Cloud.
That's literally all this is.
Now, you're going to see that in this one,
there's actually two providers.
There's access to Azure
but then there's also access to Azure DevOps.
You can't even modify any of the DevOps stuff in quirk
because the provider is not even there,
it doesn't need to be there.
That was a massive win for me
because later on when we go into Terraform,
you'll see that it actually requires
the different authentication method than the Azure normal CLI.
That was the other thing I wanted to show you guys,
which is if you separate your concerns in this way,
you do a lot of really good.
That is it.
All we want for quirk to do is just provision
and manage its own resources.
We don't really want it to do anything else.
What do we got next?
Now I think we're actually getting to the point
where we can start provisioning Cloud resources.
If we go to the Docker Compose,
which is what I use to currently deploy things,
we'll see here that postgres exists as
a container in the Cloud and so does redis.
The goal here is essentially we don't want to manage postgres.
We're going to be getting rid of the postgres and the redis,
and we're going to be leaning on Cloud
equivalent for anything that's not a quirk service.
What do we need to do?
Well, if we go back to our diagram,
we want separation of concerns to where only
what is relative to whatever it should be, should be there.
If it's not, then it should be somewhere else.
I'm creating this structure of every project has
its own Terraform Repository that it relates to.
Remember chart, we don't want to do
anything without giving it an issue.
Let's go into our project,
let's go to our board,
and let's say we have a new work item.
This is a user story.
Well, the first thing is internal only.
This cannot be public.
Which means that we will need a private network
to actually probably go back into Terraform Cloud
and remove the existing workspace of just quirk
and actually have instead something like quirk-dev.
That's a big change that we need to make.
Because what we need to be able to do is
we need to be able to make changes to our automation
and push those changes through our environments.
Should we get to creating some database?
Right off the bat, I'm noticing something which is for Dev,
we're only going to want one server.
Let's look at the single server first and then we'll move forward.
I'm going to hit "Create".
Let's go to configure server.
This is a Gen5 with four cores and 100 gigs of storage.
Looks like Azure might be telling us
a better approach might be to do the flexible server options.
There are some things we need to think about with flexible server.
For starters, we don't have a resource group.
Then on top of it,
we don't have networking.
We don't have any type of private network to be able to do this.
If we go back into our user story,
I would like to have the abstraction of
resource groups down to a much finer scale.
I love resource groups.
I think they're really cool.
I definitely want to make sure that we create a resource group.
I want to make sure that we create
our networking stack that we need
and that those are both being put in
the resource groups that we need.
What are we going to do?
We're going to go into Terraform now
and we're going to do some automation
because we now know at least what we want to move forward with.
We're going to actually create the flexible server.
Let's go ahead and get started.
We'll start, not at the very top, at the very bottom.
The last resource, which is our database.
I'm going to say touch postgresql_flexible_server.
What's the next thing?
The dns_zone_virtual_network_link touch.
Then I'm going to do the same thing for subnet.
I'm just simply getting everything placed the way I need it to.
If we look at the top, we need our provider,
so next we need our resource group.
Do we have our resource group?
What we want is we want this workspace
and all of these resources to be centric
to the environment we're provisioning in.
If we go back to our diagram,
remember, what we want is we want a generic repo.
When it runs its Terraform,
it's not just going to say,
let me just run everything.
What it's going to say is it's going to say,
I need to update this workspace
and all of the resources inside of it basically.
I really want this point to come across.
I'm not just creating a Terraform Repo
that'll have a Dev instance in it
and a production instance in it and a whatever
where all of those are in the same thing.
I'm not doing that.
What I'm saying is hey, Terraform,
I understand that you can auto-generate this stuff.
Why don't I make a repo or a module for an environment,
so that all I have to do is give the environment name,
the subscription ID, whatever else,
and it will literally take that same code
and deploy it to wherever environment I want to.
We are literally solving the problem of hey,
this broke in this environment,
now I have to go update it in every other environment.
Because we're making this a generic Terraform Repo,
I don't have to worry about staging eventually being properly
parked because staging is the exact same thing as Dev, that's it.
With these things,
there's tons of different ways of being able to approach it,
if you can make it so everything is just the same
and it expects to be the same way and that's it.
Then you're going to make your life a lot easier.
Now, we can actually work on our automation.
Let's go ahead and let's go back.
This is what we need.
Remember chat, we are making an Azure postgresql flexible server.
Let's start at the very last thing here.
Let's start with the actual flexible server itself,
and let's work our way back because
that's what we're really trying to make first.
The name of this database is going
to be the name of the workspace.
Let's go ahead and let's go to the resource group now,
the next thing is our actual subnet.
This subnet means that
this is only for databases now, if I do this.
Now we have a virtual network that we also have to do.
Let's go to virtual network.
The virtual network is like our VPC essentially with AWS.
It helps me a little bit more with what I want to do.
What I'm going to do is I'm going to say, workspace.name.
We will have one virtual network
that all of these things will exist in.
Go back to our resource groups.
We've got databases, but we need a couple other ones.
Not only do we need databases but we also need one for networking.
We've got that set up if I'm right, which hopefully I am.
I do you lazygit.
We can see that
my resource group is now using var.environment.
Always try it and see if it does,
if it doesn't, try it again.
Let's take a look. I think for now
what I'm going to do is I'm actually going to keep it like this
and I'm just going to continue with it.
Basically what we're going to do is in feature postgresql,
I will add the locals,
we'll make sure that we create
our resource groups for network and database.
We'll make sure our subnet gets created,
make sure our variables gets added,
and all of this basically.
When I push this up,
my hopes are that I should get two plans here
once I open this PR.
Work, Create PostgreSQL Server, create.
I'm hoping it runs it against both.
There we go chat.
There it is.
Now we're running plans against quirk.
This is why I wanted to do this so badly.
All I have to do now is check and see will it work in Dev,
will work in prod.
The prod plan,
quirk-prod, prod-database, prod-network.
That is how you can deploy the exact same setup
in multiple environments
and make sure that it's consistent
across all of those environments.
What I just showed you guys today is literally how you can do it.
Now, all we have to do is just modify some things.
All I have to do is refresh this page
and I should immediately trigger two new checks.
There we go.
There's my new commit.
If I refresh, there they are, new checks are running.
Cool. This is all looking good.
Now, here's where I wanted to show you
how you control this stuff going out.
We're not going to complete it,
but we're just going to merge it.
Cool, so we merged it.
Now what we're going to do is we're going to go
to the repo itself here
and we're going to refresh.
I don't have to worry too much.
Again, I'm just basically
doing automation against the Dev environment.
I'm not actually applying this anywhere else.
There you go.
We have two new pending.
Look at that.
There's our private DNS zone.
Sure enough.
Now we're almost at the point of creating the database itself.
Let's look at a postgres flexible server.
We know we've got all that setup,
but now what we need to do is see if we can actually
provision this database to that resource group.
We should see variables which has been
variable postgresql_administrator_password,
the environment password.
Because now I've got this really easy workflow where it's like,
well, if I want to deploy to prod, I can do this.
If I want to deploy to Dev, I can do this.
It's just very easy for us to be able to keep going through this.
But now, again, same thing as always.
Go back, create a new pull request.
Let's see what happened.
But I've always enjoyed solving problems.
There it is, sensitive.
There we go.
quirk-dev-database, B_Standard.
We're good.
It worked.
That's so awesome.
That worked.
Now if I go in here and I hit "Refresh".
Yeah, there it is, quirk-dev.
Let's go to quirk-dev-database.
There it is.
Chart, we did it.
We created it.
We finally created our database.
I would say today, incredibly successful day.
Men, so much good stuff we got done today, it's insane.