DevOps Question (one man army edition)

I’ve been building in-house web apps for my company for a few years now. Word has gotten out, and now there’s a “rush” for these small apps all over the place.

I’d like to get away from building and configuring the full stack LAMP apps, which is what I’m currently doing. So, I’ve been looking into the DevOps meme.

These apps aren’t anything too sophisticated, so it’s not like I’m building Facebook or Instagram; however, designing the app, configuring the server, and building the whole thing from scratch, and deliver on all these request, in addition to keeping up with my other responsibilities seems like it’s going to be kind of tough.

Therefore, I’m considering using Vagrant, Chef and Rails to accomplish this.

Anyone been through this before, or have any protips?

Any advice would be appreciated.

Thanks!

Cotton

Vagrant almost always targets VirtualBox guests, and you’ll almost never be running VirtualBox in production. There is a KVM plugin for it, but porting still requires developer time.

It seems to solve a problem that is better solved by not giving your developers Macbooks.

Chef is fine. I hated working with it, but it worked fine. Puppet, on the other hand, scales poorly and requires shoehorning to run masterless. I like Ansible better. It seem more suited to grizzly *nix veterans who need cli-like power at scale.

For apps that don’t require state and HA at the same time, git for source code, docker and docker compose give you a dead simple workflow that scales pretty well.

I do my personal stuff that way, and I like the “shoot it in the head and deploy a new one” mentality way more than fighting with systems to (try) making them consistent.

1 Like

Ansible for setting up physical systems.

Docker for the development platform

Docker Compose to tie the two together, (also nice for integration tests).

That’s how I’ve been rocking, and life is good. Also, if the underpinnings of these systems are all the same, or very close, you probably only need one set of Ansible playbooks for the whole fleet.

I would start out by bringing all the existing systems under Ansible control. Then you can bring a new one online with only slightly more work than an up arrow -> enter. (Don’t tell your boss that right away).

2 Likes

If you want to do as little as possible for each new app, it makes sense to reuse as much infrastructure code as possible. Start by combining the repos for those projects, including whatever scripts you have to deploy infrastructure, then write a few basic smoke tests and the rest will fall into place.

You’ll likely see some common patterns between your projects that’ll reduce the marginal cost of doing new stuff. You might even end up maintaining / supporting your existing apps (shocking😮).

1 Like