Skip to content

brainfood / docker-image-recipes

Go to a project
Toggle navigation
Toggle navigation pinning
7fdfa497 by Adam Heath
Options

Add LICENSE and README files.

1 parent f92a3ab2
Inline Side-by-side
Showing 2 changed files with 57 additions and 0 deletions
1 The MIT License (MIT)
2
3 Copyright (c) 2017 brainfood.com
4
5 Permission is hereby granted, free of charge, to any person obtaining a copy
6 of this software and associated documentation files (the "Software"), to deal
7 in the Software without restriction, including without limitation the rights
8 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 copies of the Software, and to permit persons to whom the Software is
10 furnished to do so, subject to the following conditions:
11
12 The above copyright notice and this permission notice shall be included in all
13 copies or substantial portions of the Software.
14
15 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 SOFTWARE.
1 This repository contains a series of simple docker image recipes. These are
2 meant to be referenced via docker-compose, and built for each project
3 separately. No sharing of images. This provides sanity for each project, as
4 you don't have to worry about an image changing underneath you. It also means
5 that you can be certain you can rebuild on your own whenever the situation
6 calls for it.
7
8 Here are the best practices in these files:
9
10 * Generally, any image listed here should run without any external
11 dependencies. No includes from other images, etc. This makes it easier to
12 understand and extend.
13
14 * Each Dockerfile is designed to have minimal layers. This makes rebuilds
15 faster, as there are less docker-runs. It also makes many things easier to
16 accomplish, as there is a real shell script that can do sophisticated
17 things.
18
19 * Images also tend to make use of standard, unmodified debian packages. Let
20 someone else do the hard-work of system integration, while these recipes
21 then just do slight tweaks.
22
23 * Any files that need to be shared between a host and a container should make
24 use of UID/GID being sent in from the host. The daemon in the container
25 should run as the UID/GID, and it's files changed to have that ownership.
26
27 During entrypoint, the target container user is then modified to have the
28 correct uid/gid setting. If there is no target user, then one should be
29 added during the image build, generally calling it hostuser/hostgroup.
30
31 * Daemons that have complex binary file setups should have those files created
32 during image build, then the entire structure placed in a tarball. The
33 entrypoint can then extract this seed tarball, but only if the target
34 directory is empty. This allows for the volume mounting of these
35 directories from the host. Make certain the uid/gid mapping is sane when
36 this occurs.