Skip to content
Toggle navigation
Toggle navigation
This project
Loading...
Sign in
brainfood
/
docker-image-recipes
Go to a project
Toggle navigation
Toggle navigation pinning
Projects
Groups
Snippets
Help
Project
Activity
Repository
Pipelines
Graphs
Issues
0
Merge Requests
0
Wiki
Network
Create a new issue
Builds
Commits
Issue Boards
Files
Commits
Network
Compare
Branches
Tags
7fdfa497
authored
2017-09-18 11:41:19 -0500
by
Adam Heath
Browse Files
Options
Browse Files
Tag
Download
Email Patches
Plain Diff
Add LICENSE and README files.
1 parent
f92a3ab2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
57 additions
and
0 deletions
LICENSE
README
LICENSE
0 → 100644
View file @
7fdfa49
The MIT License (MIT)
Copyright (c) 2017 brainfood.com
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
README
0 → 100644
View file @
7fdfa49
This repository contains a series of simple docker image recipes. These are
meant to be referenced via docker-compose, and built for each project
separately. No sharing of images. This provides sanity for each project, as
you don't have to worry about an image changing underneath you. It also means
that you can be certain you can rebuild on your own whenever the situation
calls for it.
Here are the best practices in these files:
* Generally, any image listed here should run without any external
dependencies. No includes from other images, etc. This makes it easier to
understand and extend.
* Each Dockerfile is designed to have minimal layers. This makes rebuilds
faster, as there are less docker-runs. It also makes many things easier to
accomplish, as there is a real shell script that can do sophisticated
things.
* Images also tend to make use of standard, unmodified debian packages. Let
someone else do the hard-work of system integration, while these recipes
then just do slight tweaks.
* Any files that need to be shared between a host and a container should make
use of UID/GID being sent in from the host. The daemon in the container
should run as the UID/GID, and it's files changed to have that ownership.
During entrypoint, the target container user is then modified to have the
correct uid/gid setting. If there is no target user, then one should be
added during the image build, generally calling it hostuser/hostgroup.
* Daemons that have complex binary file setups should have those files created
during image build, then the entire structure placed in a tarball. The
entrypoint can then extract this seed tarball, but only if the target
directory is empty. This allows for the volume mounting of these
directories from the host. Make certain the uid/gid mapping is sane when
this occurs.
Please
register
or
sign in
to post a comment