Curious about configuration management for your VPS?
Here’s a situation you might have found yourself in lately—you set up a local development environment for your new website, spent dozens of hours coding it up, only to find that when you transfer it to your VPS, it doesn’t work properly.
The issue? Well, it could be any number of things, but one of the likely culprits is discrepancies between software versions on your local environment versus software on the server. Because the two environments aren’t quite the same, something in your code goes wrong. Troubleshooting the issue can be taxing and time-consuming, if not impossible.
Software configuration management (SCM, or just CM in IT discussions) aims to help minimize the chance of this scenario by establishing baseline environments that can be replicated anywhere you choose. Once you create a configuration, you can deploy that to your local dev environment and the VPS, ensuring that everything will work smoothly.
Only $119/yr for 48GB RAM and
480GB 960GB NVMe and free backups for LIFE!
Celebrating our 9 year anniversary! Capacity is limited and some deals will sell out. Get yours before they are gone!
But, that’s just one of the many benefits to rolling CM into your development and administration workflows. Whether you use a single VPS or many working in synchronization, you can work smarter and faster with CM in your life.
Why should I use configuration management on my VPS?
In many ways, CM converts servers into code. This gives you complete control on top of enabling common development practices, such as version control, code reviews, and automation. This creates a number of positive use cases.
Ensure that all environments are equal
In the scenario mentioned above, CM allows you to create a environment that can be replicated in a number of different locations. For example, you can use local virtual machines for development, transfer your code to an identical testing server for review, and then push to yet another identical production server. Because each environment is identical, deployment should go smoothly.
Roll out new servers quickly
If you spent any time with our tutorials on setting up SSH or installing a LEMP stack, you’ll understand that setting up a new VPS the right way—basically, with any degree of security—takes time. Instead, you can provision a new server via the SSD Nodes dashboard, point your CM to its IP address, and have a completely configured server in a matter of minutes.
Restore from failure faster
Whether you’re hosting a blog or a SaaS application with paying users, you want to recover quickly if something dramatic happens, like a database failure. Because new servers can be rolled out so quickly with CM, you can take the failed server offline for later analysis, start up a new one, and get back in action. That is, without a doubt, going to be faster than trying to restore the existing server while your viewers or customers wait.
Better security overall
While first setting up your CM tools, you’ll want to ensure that you take some basic server hardening steps, such as establishing SSH key-based authentication, restricting root logins, setting up
fail2ban, and much more. Because this happens automatically with every new server, you reduce the risk that you forget a critical step or make a typo that leaves your production server open to hackers.
Control your servers like code
A CM script—they’re called playbooks, manifests, and recipes between different tools—is a piece of code, whether it’s YAML or Ruby. That means it can be kept in a Git repository and tracked as you would any other aspect of your code. With more transparency comes a better ability to improve upon the work you’ve already done, especially if you bring others onboard as well.
There are other positives to CM as well, but those are some of the primary benefits.
Which toolset should I pick?
Of course, we can’t say for certain which toolset will work best for your needs—each have different philosophies, use different languages, and have different costs associated with them.
There are a few primary contenders today: Ansible, Chef, Puppet, and SaltStack. Each have an open source component that can be expanded into a paid product if you need additional features or technical support.
We won’t go too deeply into the details here, since we believe that every developer or team needs to find the solution that’s right for their skills and particular needs, but here’s some important questions to keep in mind as you’re researching the options:
- What scripting language does it use? Which are you most comfortable with?
- Do you want or need to install remote management software on your nodes?
- What are the transport methods used?
- Which development, staging, and production environments do you need to work with?
- How established is the community around this solution?
- Is the solution proven at the scale you need?
In his blog post comparing the options, Emir Ozer brings up a good point:
One thing you should keep in mind that which tool you choose to use doesn’t matter if you aren’t using anything. Automation is always > no automation. You will benefit from any of it.
If you’re not using CM right now, all of the solutions will help you ensure clean, consistent environments that can be set up in a fraction of the time otherwise—before you roll out a new VPS, see if you can’t experiment with some ways of making those first few hardening steps a little smoother. And if you’re already using one solution and are evaluating another, try it out for your next open source project, and see if you don’t like its particular philosophy more.
- Choosing a deployment tool - ansible vs puppet vs chef vs salt
- Puppet vs. Chef vs. Ansible vs. SaltStack
- Configuration Management: Which should I choose: Chef, Puppet, Ansible, SaltStack, Docker, or something else?
- What is difference between docker, puppet, chef and vagrant?