This is a part of my HashiConf 2025 talks.
Resources
Background
As a developer, it's quite common to get an issue which not replicable. It's either an undetailed or an assumption replication of steps, a configuration issue, an environment issue, etc. I believe some developers face issues when in production it doesn't work, but in their local was working. There is a common slogan, "it's work in my machine." So, why don't we bring our machine then?
Motivation
We need to kill the configuration/environment issue. There is a great tool called Vagrant. I want to emphasize why Vagrant? Because it promises consistency. When in my machine works, of course, in yours, and should be productions!
Challenges
- When I developed some functionality, there was an issue that only happened in production. Either because different operating system, a different configuration, etc. Of course, when we use Vagrant, we are able to use the same operating system.
- How about the configuration? Yes, we can ensure the same config as production. It doesn't mean you will have the same architecture, but at least you have the prototype.
Trade Off
Every choice will have a trade-off. For example, we will face the power of the host machine. Not all organizations will choose a very fancy specification. This will become a bottleneck. When they don't want to switch into the same operating system, but don't want to spend more money on providing more powerful development devices.
Well, let's talk about why we use Docker directly. Of course, I will say yes, if...
- The operating system is the same as our target server.
- Having a mechanism to have the same configuration.
I faced some organizations having their developers which different tools, different operating systems, which is not appropriate. Okay, for example, I have a Windows operating system, but I want to run Docker. Oh well, we may say, oh, that's better. It's more reasonable now, lighter.
Well, I was part of modernization and or refactoring from .NET Framework to .NET Core, which supports more operating systems. Back then, I faced a lot of problems when we started containerizing it to become a Linux container. Either it's only running in my machine, or just environment issues.
For example, oh, I can run it in my local environment because I have some proper configurations. But the production doesn't know it, which is not a good one. Then, how about talking about the changes to the operation team regarding changes. Well, how long will it take? They have some BAU (Business As Usual). Some requests may not be taken into account.
Oh no, so what will we do? Imagine...
- The developer can make some changes in their Vagrantfile.
- We have set the automatic system to detect the changes.
- If we get the changes, we start to sync them with production.
- Yeay! We win it!
But, but, ... I can't say the current state of Vagrant is developer-friendly. It's a little bit operations team part. I would say it's a shared responsibility between the developer and operations. Well, at least it's a code, developers should learn it (sorry).
Summary
- The providers may not matter. I select VirtualBox, because most of us are more familiar with it, but please select any providers that fit with your compliance. Maybe the other VM Virtualization will work. Please take note, why we don't choose Docker as a provider, it's a bit complex (oh, I mean more confusing) than the other. Because it will run a VM whenever it's not supporting Linux containerization.
- Choose any provisioner that meets your requirements. I love how Docker provisioner works. Even sometimes I still need shell. I really hope the provisioner will grow up. Why? So we can easily get the high-level of Vagrantfile (without AI, of course, sorry AI).
I understand we can improve our work with AI, but please understand the fundamentals. It will really help instead of blindly using AI, and (boom), you don't know what AI said.
Finally, feel free to give any feedback. Any feedback is welcome, even if you do not agree with this article/supplement. I just want to share my perspective. Every team/organization may have its own challenges, which is why sharing is caring. I really love to learn how they tackle their challenges. It's really inspiring!
Top comments (0)