Hello, env0 fans! It’s a huge day for Infrastructure as Code users all over the world. Today env0 is enabling the ability to automatically detect drift and make sure your real-world resources in the cloud provider are aligned with your Infrastructure as Code files. env0 will alert you once a drift has been detected and gives you the ability to view and fix the drift, which can help mitigate one of the main challenges when using Infrastructure as Code!
To answer this question, we have to take a quick step back for anyone who isn’t up to speed. Drift is the name given to the situation where the resources that are actually deployed to the cloud, aren’t matching with what your infrastructure as code files in your repository says should be there. Your repository should be your “single source of truth” when it comes to your infrastructure. Usually, drift happens because someone circumvented the procedure and went into the cloud to manually make resource changes, instead of updating the Infrastructure as Code files and re-deploying properly. Now, we can set up an automated process that checks for these configuration drifts on your schedule and alerts you when it is detected.
In the past, 3rd party tools would have to be used, such as driftctl. For a while, you could set this kind of functionality up in env0, but you would end up with a queue of deployments unless you went in and hit cancel on the plan each time it ran that had 0 changes to the infrastructure. Now, we’re solving this issue simply by creating a Policy inside env0 to “Skip apply when plan has no changes.”
This is the best part of the whole thing. It’s as easy as 2 checkboxes and copying and pasting a cron statement, pending your environment is configured to wait for approval, and you have notifications enabled on the project. If you haven’t done that yet, you can find the docs for notifications here. Approvals are set up at the project level, and when you deploy the environment.
Let’s start with the scheduling. This will be done for each of the individual environments you deploy. You will go into the Triggers tab on the environment and go to the Scheduling box. For my example, I set it to run every 5 minutes. If you need help generating your desired cron schedule, you can find a tool here. Once you do this, it will create a new deployment every X number of minutes, hours, days that will run up through the Plan phase.
Now, we need to go into the Policies tab under the Project and enable the “Skip apply when plan has no changes” policy. If we don’t have this check box enabled, then the deployment will halt and require either an approval or a cancellation every 5 minutes when it runs. That can get annoying. We don’t want to have to get involved in any way unless there is actually a configuration drift.
And that’s it! See how easy that was?
Now that we have our environment deployed, we enabled the “Skip apply when plan has no changes” Policy, and our schedule is set up, let’s see what happens when our plan runs with no changes to the plan:
We can see that it runs through all of the steps and because we have the new Policy enabled, it just finishes out the deployment process without actually requiring any human intervention. Cool huh? So what about the other side of that coin. What happens when someone goes in and messes something up? Let’s say that our CTO, Omry, decided he wanted to go in and just delete one of my instances. Maybe he thought it was his, maybe I made him mad in some way. Who knows? All we know is that we now have drift. The resources deployed to the cloud do not match the resources our Infrastructure as Code files say should be there.
Our environment is now Waiting for Approval. We get an email from the platform about it, and since we have Slack notifications, we get one there, too. When we click that notification it takes us right into the platform and shows us that our plan says we have 1 resource to add. So let’s approve that change, fix the drift, then go ask Omry why he was in there messing stuff up manually instead of following the correct deployment procedure.
And just like that, our Apply to fix the drift is done, and we’re storing state. Problem solved!
And that’s it! We’re super happy to have this small change that enables a very powerful check on all of your Infrastructure as Code environments. If you have any feedback or feature requests, feel free to reach out! Or if you’d like a live demo, simply schedule a demo with us.