1. 4

Hi,

I posted this as a comment and received the suggestion to open an Ask Lobsters thread.

I’ve spent some time looking at Docker this week. I’m trying to solve some problems and, for what I’ve read, it seems to be the best answer:

  1. Have the same environment on all machines, development and production. Our server runs linux, most of our devs use OSX.
  2. Be able to work offline (in trains, planes, etc) without the need to be connected by ssh. This makes sense in our environment, not all commands are the same on Linux/OSX, etc.
  3. Sync all project files through all machines, i.e. if I change code, or insert some rows in the dev database, I want these propagated to other devs. For code we use git, but I’m not sure what to use for other assets (images, DB…)

So I’ve read that Docker solves 1 and 2, but I’m not sure about 3.

I don’t want/need it to be super complex – no Vagrant deployments, elasticity, etc. Just let some devs have a uniform environment regardless of their machines and internet connectivity and a way to sync their work.

Maybe I’m confused and I’m looking at this problem the wrong way – if so, tell me indeed! I hope we can share our solutions to this problem.

Thanks!

  1.  

  2. 2

    For 1) and 2), I would use something like Virtualbox, without Vagrant but with chef-solo or equivalent inside. Really you can use anything that runs virtual machines. Unlike Docker, this has the advantage of running on a variety of host systems and doesn’t necessarily require systems to be configured from “outside,” such as from a Dockerfile or Vagrantfile. For chef, here’s a minimal example I made for myself, and here’s the same basic concept for a set of real systems. I went with chef because a friend argued persuasively that it’s worth the effort.

    For 3), keep a dump of the dev database checked into source control, and have it be part of the dev environment configuration process to drop and recreate the database from this known starting point.

    Docker is primarily a tool for deployment, and I don’t believe it’s suitable for development. Docker’s promise of easy, speedy deployment comes at the cost of setting up all the other operational infrastructure around Docker to make it work.

    Expect to spend a bunch of time working with your team to experiment with your system; it’s going to be slow-going at first and the point is to evenly spread knowledge about its use without leaving people in the dust. Problems you might run into include sharing standards for base images and networking crap. Many developers believe that good tests help influence the design of good code through ideas like dependency injection; a good shared dev environment should hae a similar effect on your systems. In my experience, Heroku’s 12-factor app methodology has had a transformative positive effect on the shareability of my code.

    1. 1

      Sync all project files through all machines, i.e. if I change code, or insert some rows in the dev database, I want these propagated to other devs. For code we use git, but I’m not sure what to use for other assets (images, DB…)

      I find the idea of docker repulsing so I’ll stick to what I know: How do you use these images and the data in the database? What size are the individual images and their total size? What prevents you from having .sql files with database schema and database data that you version control and share like normal text files?

      1. 1

        Let’s say we have a production DB and a development DB. Whenever I create a new module with some tests, I need data on the dev DB to run those tests. An option I’ve used in the past is to copy the database files, but they tend to be big (GBytes) in the long run.

        It could be rephrased as, what to use instead of git for syncing development DBs?

        1. 3

          Your dev DB files don’t need to be big. Tests should only require tiny databases; I’ve never encountered a situation where more than (say) a few dozen rows of test data are needed to ensure that a test works.

          1. 1

            You can use git-annex or git-lfs to deal with huge files or binary data in a reasonably nice way, without breaking your usual uses of git.

            Looking at things a very different way, if you have replication set up and a canonical source for the dev db, you could have a regular step where you connect and replicate.