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

[Rich Freeman <r-plug@thefreemanclan.net>]

On Wed, Aug 24, 2016 at 10:39 AM, Andrew Libby <andrew.libby@gmail.com> wrote:
>
> On 8/23/16 9:39 PM, Rich Freeman wrote:
>
>> 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.

I can buy that, though often there is caching data that I'd prefer not
be re-created every single time an instance starts up, even if it
could be.  And I'd prefer not to have for every single instance a
laundry list of bind-mounts to stuff outside the instance, or
whatever.

It still leaves me with an issue.  I create a home mythtv server
image, for example.  In two weeks I want to apply package updates to
it.  Even if I roll back to the image file every time I start an
instance, I still need to launch an instance, deploy my updates, and
then capture that as a new image.  Either that or I'm building a new
image from scratch every few weeks, which would be painful.

For many of my images I'm going to probably end up starting from
scratch and not using the registry.  Or, at best I'll end up being the
person maintaining the registry, though I don't know if I'm going to
bother keeping a generic OS-only image since I'm not using anything
like Chef/Ansible.

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

I really don't like the idea of using an application that does image
management, and then trying to manage my images outside of it.  I feel
like I'd end up fighting Docker.

If I wanted to manually maintain snapshots at the file level I'd just
stick with nspawn.

>
>> 2. How to build docker images from directory trees or using installers/etc.
>
> 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.

So if I were going to go that route I'd use Ansible or Chef.  However,
I'm content with just setting up a host once and then maintaining the
image over time.

>
>> 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.
>

Actually, it looks like it just uses btrfs natively automatically if
built with btrfs support.  I just need to figure out how to get it to
snapshot instances into new images and such.

Thanks - I'll keep tinkering with it.

-- 
Rich
___________________________________________________________________________
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