![]() new versions of APT packages becoming available, causing differing package versions to get installed on production).ĭocker solves a lot of these problems. Or, in a deployment scenario, where I have to worry about external sources being unavailable (APT repositories, GitHub, ) or dependencies mutating between development testing and deployment time (e.g. ![]() Or when I come back to a project months later and hit a red status due to a piece of the playbook now being broken. Well, it’s satisfying unless I’m in a hurry and don’t want to wait 10+ minutes for all the machines to get provisioned. There’s just something so satisfying about typing vagrant up and watching machines get spun up by Vagrant, and then seeing the green Ansible statuses slowly scroll by as the playbooks install the necessary software and libraries to run my code. Eventually, after getting sick of the slowness of virtual machines (Vagrant’s default provider is VirtualBox), I switched to the excellent vagrant-lxc plugin, which allowed Vagrant to provision lightweight Linux containers ( LXC) instead of VMs. Until recently I had been pretty happy with my development provisioning setup, which consisted of Vagrant for spinning up development machines and Ansible playbooks for provisioning the software I needed installed on them. I’ve spent the last several weeks learning Docker and porting a Rails project’s development environment from Ansible provisioning to Docker, so I thought I’d share my experiences so far. If you’re like me, you’ve probably been hearing a lot about Docker over the past year but haven’t really gotten past the “hello world” tutorial because you haven’t found a good way to integrate it into your development workflow or staging/production deployment process. An example Vagrantfile using the Docker provider.Rails Development Using Docker and Vagrant
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |