Automation Providers Q&A

[00:00:00]
>> Where do tools like Ansible fit into all this?
>> So Ansible is configuration focused, right? Ansible is what you run after everything's already been provisioned. And Ansible is really just about what we said earlier, who can change the values or configurations in services and other parts of my infrastructure, right?

[00:00:26]
Ansible can do a lot of things however I would strongly urge you to not use Ansible as a one off solution tool. The biggest reason for that is because then Ansible just becomes bash scripts [LAUGH] at the end of the day, it really does and you know it equally with bash scripts can be very flimsy or very effective depending on how well you implement them.

[00:00:51]
At Hippo, we do use Ansible but we only use it for service configuration. That's it. So Ansible role will run against our service configs and update everything. It doesn't create anything, it doesn't delete anything, it doesn't move anything, it just takes values that already exists and changes them if they need to, right?

[00:01:13]
I don't really use Ansible that much anymore these days to be honest, cloud providers and automation tools have gotten so good now in a lot of ways where most of the stuff and expectations that you need are already there, so you just don't really need to use it.

[00:01:30]
I would say be careful with what you want to do with Ansible and try and like even with this, focus one thing at a time. [LAUGH] You can use Ansible to setup your dot files, like your developer environment if you really want it to, Ansible is so flexible.

[00:01:48]
Just try and keep that focus because again, it's kind of a wonder tool, and you don't need a wonder tool. [LAUGH] Okay, any other questions?
>> Does Ansible make sense for on-premise cases?
>> I think the only thing Ansible really makes sense for us is if you're a single person trying to connect to a bunch of things at once, because that's just really what it does.

[00:02:15]
If you are an individual who's managing a bunch of on prem stuff, and you want to at least get some automation started, then yeah, actually, I think it's a great place to start. Because you probably already have SSH in place, right? You probably already have some basic stuff there, but you don't wanna have to manage all these other things yet, then that sure that could help.

[00:02:40]
But that also might mean that your on prem solution doesn't have really great automation API's, right? And you might have to do more manual stuff, so I could see where Ansible could help there.
>> To build on Luke's question, can one use Terraform Pulumi to manage self hosted on prem resources.

[00:03:00]
>> So Terraform and Pulumi are going to require on a provider already existing, right? So when I told you guys before I used to run my own on prem stuff, I ran something called VM Ware V Center, V center does have a Terraform provides. So that gave me the ability to write Terraform code and create my resources with it.

[00:03:23]
But if there's not a provider for it, unfortunately you can't use the automation tool, yeah. That's when Ansible would come in for sure. There's this automation that's creating these things for you, right? But it has to have access to a lot of permissions to be able to do that, just to make sure that you don't create and delete everything underneath the world, right?

[00:03:43]
And so I believe what they're saying is, how do you make it so that if this is creating a network, it can only create a network, right? It can't also touch lambdas or EC2s or other things like that, right? Like how do you do that? That's honestly that's a tough problem to solve.

[00:04:02]
It really is.
>> You said exactly that's my
>> Yeah, we have not solved that at HIPAA, [LAUGH] we just have a global admin key, yeah. Why? Because it's so hard to predict like what's the next thing. And we found ourselves like what they said. Okay, now we got to add these permissions and these permissions, and it's dude, no, okay?

[00:04:29]
Terraform, you just manage everything, okay? We trust you, just do it. Security might not like you though. [LAUGH] The security team might not like that you're doing that though, but when if you wanted to really argue it, you could just say that it's about saving time for money.

[00:04:47]
How many hours do you want us to spend every time we change a permission trying to figure out, we have to collaborate on that, you got to tell me what permissions you need. I don't think it's valuable. I think what you should do instead is focus on your security of your keys as well as your rotations.

[00:05:05]
For me, I'm not really worried about keys, as long as I can rotate it as quickly as possible. So, a good example of this, Circle CI had a data breach about a year ago. I don't know if anyone had heard about this, but it was huge to the point where Amazon even stepped in because so many companies did exactly what we do.

[00:05:23]
They just set up their Circle CI to have access to everything, right? And so when that outage happened, Circle CI actually had to go to Amazon and then they work together so that Amazon would go in and reset all of the keys that were exploited, right? Yeah, I mean it's tough.

[00:05:45]
It's not fun and what our takeaway from that was is maybe don't store secrets in Circle CI anymore. [LAUGH] That was our takeaway there, it really was. So yeah, it's got to be an organizational decision. And you need to be aware of the decision you make, yeah. But for us we just said, just given access to everything it's a specific key only.

[00:06:13]
It's kinda like the Coca Cola recipe, only two people know it exists, [LAUGH] only two people know how to access it. So keep it locked down, yeah. Any other questions? Yeah.
>> Are these, like this approach is this well defined enough or mature enough that you can switch cloud providers easily enough or is that are you still fairly locked into to

[00:06:39]
>> You mean the automation providers?
>> Right, so if you have automation providers, could you switch from Amazon to
>> Yeah, absolutely.
>> Almost seamlessly or is it
>> Well, so if you wanted to move from like Amazon to Google, you'd have to create the resources for that.

[00:06:56]
But what's nice about these providers is they can talk to any of them. It's not just Amazon or whatever. So we gonna go over this in the course a little later, but if you modularize it well enough, you could have a module for Amazon, a module for Google, and then just have Terraform run all of those.

[00:07:15]
>> Do you recommend infrastructure as code for database provisioning and management?
>> So that's something I thought about adding in this course, but because of so much we have to do, I ended up not doing it. In that section, yes, separate them though. Create your databases in one automation pipeline and then create your, I'm sorry, create your instances in one automation pipeline and then create your databases in another.

[00:07:47]
Why? Well, because this can then depend on this. So if you need to change this, you don't have to change this too. Whereas, if you bind them together, then not only does Terraform have to change your instance, it also has to be able to access it and connect to it, which then makes it even more challenging for the pipeline to be able to do so.

[00:08:08]
Then we go back to permissions and things like that. That container now can do more things, whereas we say, okay, here's the Terraform for our RDS instances, here's the Terraform for our Postgres databases. And this just takes a value of what the RDS instance URL is, and just connects to it and runs it, right?

[00:08:29]
So over here, I can change the database URL, have all the same automation and have it run against a new database or something like that. So I do think it's important to just separate those two. That is what I do I have a workspace for all my RDS instances and then I have a workspace for my databases and stuff, yeah.