nginx/default /etc/nginx/sites-enabled/default ADD.
#Docker vs vagrant install#
This results in the directory structure below.įROM ubuntu:latest MAINTAINER Tyler Cipriani, # Download and install php, nginx, and supervisor, hey, just linux for a change! RUN apt-get update RUN apt-get install -y software-properties-common RUN add-apt-repository ppa:nginx/stable RUN apt-get update RUN apt-get -y dist-upgrade RUN apt-get install -y php5-fpm nginx supervisor # Setup config files RUN echo "daemon off " > /etc/nginx/nf ADD. To keep my project directory nice and tidy, I’ve separated-out most of the files needed by the Docker provider into a Docker folder. “Imma setup a local development environment for Ubuntu 14.04, nginx and php-fpm using Vagrant, Supervisord and Docker,” says I. Using Docker as a provider means that you can run a fully-independent development enviroment, on your host machine without the overhead of VirtualBox. While Docker is still a Linux system-and, ipso facto, state-dependant-it’s also ephemeral and therefore, by not persisting changes to state, Docker has created a previously unavailable (on bare metal hardware), lightweight workaround to the problem of system state.Īs is my wont, I decided today to play a bit with Docker on Vagrant and, lo-and-below, I found that the newest version of Vagrant (1.6.2, as of May 26th) can actually use docker as a provider, that is, as an alternative to VirtualBox.
I feel Docker addresses the problem of program state better than other currently available solutions (although, Nix is looking pretty promising as well). This system state adjustment may or may not be reflected in the chef repository (which double sucks).
Maintaining a bare-metal, long-running server non-interactively using Chef sucks because any hand-tinkering via ssh is going to fuck with the “state” of the system-creating different results for subsequent chef-client runs. Linux system administration is difficult because Linux commands are non-deterministic and rely heavily on system state (e.g., installed software, permissions, network settings and availability). I’ve come to the realization that my problem with Chef is not really a problem with Chef, but a problem with Linux itself. Further, Chef allows you to keep a(n ostensibly) well-tested system under version control. This thought is usually fleeting: Chef provides many needed abstractions that are, ultimately, much easier to grok than the underlying Linux system. Often is the time, in moments of profound frustration, that I’ve had the thought that Chef is nothing more than a useless, leaky abstraction that separates me from something I know fairly well-Linux. I’ve been thinking about Chef a lot lately. I tend to use the Chef provisioner with Vagrant to build-out a local environment that matches my server fairly closely. I enjoy being able to spin-up toy linux environments to test out ideas.
I’ve used Vagrant a fair amount in my day, and it’s great.
0 kommentar(er)
