Re: [PLUG] Docker Best-practices guide / intro?

[Andrew Libby <andrew.libby@gmail.com>]

Hi Rich,

I've been waiting for others to chime in hoping you'd get some
good advice.  I'll take a crack at it as I've been using docker for
about a year or so.

I don't have much of a pointer as far as a best practices guide.
I started with the docker documentation.  It's good though it's grown
quite a bit and can be challenging to navigate.

I've been making a habit of hanging on the IRC channel if you want to
chat about it.

Andy

On 8/23/16 9:39 PM, Rich Freeman wrote:
> Can anybody suggest a good intro to Docker that emphasizes doing it right?
> 
> I don't need containers 101 (so, prefer this not be 99% of the course content).
> 
> What I want to learn is:

> 1. How to create/start/stop/snapshot/maintain/etc docker instances.

At my last job we built a number of docker images to run various
services.  This included things like rails and perl applications,
java apps that were closed source, LDAP, mysql, postgres,
and so forth.

We initially were using systemd units to manage start/ stop containers
but wound up using the docker system itself and have containers
typically --restart=always passed to docker run.

Since docker images are themselves somewhat like a snapshot, but we're
careful to keep application data out of the image and stored either in
a database linked to the comtainer or in a persistent volume.  Generally
I used volumes mapped to a direcotry in /srv devoted to the container.

If I were to do application snapshots, I'd use the underlying
filesystem/ storage technology to perform those snapshots.

> 2. How to build docker images from directory trees or using installers/etc.

Looking at the docker build documentation and reading the Dockerfile
reference will help a lot here.  Folks I've worked with and I have had
varying philosophies on building images and how to go about it.  I
tend to favor simplicity even if it means the image isn't very generic.
At times I've gone the extra mile go make an image generic to suite
a variety of needs.

I generally keep copies of configuration files for the service in
git and copy them into the image at build time.  Some folks have
docker RUN statements that use things like sed to edit configuration
files for the services that are already in the base image they're
building from.

> 3. How to set up applications on reputable docker images and save
> those as new images/etc for deployment.

We leveraged both the public docker registry and would push our images
to it.  We also ran a local docker registry.  Some of this was for
performance, some of it was so we could keep non-open source code inside
an image and not push it to a public registry.  You can rent a private
registry if you like as well.

> 4. How to leverage btrfs snapshots if possible, since I'm running this
> on btrfs anyway.

We had some btrfs, and while we didn't snapshot with it, I imagine you
could have subvolumes in /srv (to riff on our approach), and snapshot
those.  I imagine that'd work fine.

We also experimented with keeping application data that non-ephemeral
and not appropriate for keeping in mages in ceph.

> 
> What I don't want is:
> 1. curl <url> | sudo sh
> 2. Search for application name; install random container from
> who-knows-where; run container; try not to be home when FBI kicks down
> door.
> 
> I'm probably going to run one each of a few container images.  I'm not
> spawning hundreds of application servers that have to talk to my
> database/etc.  I don't mind manual configuration of hosts.  Right now
> I'm just doing it all with nspawn, but I think docker might be an
> improvement (easier to use non-root containers, simpler to
> snapshot/template/etc).
> 
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug