-
Notifications
You must be signed in to change notification settings - Fork 4
Docker image guidelines
This consolidate common patterns and best practices used across all images built & provided by @lncm. All rules are numbered for the ease of reference.
This applies to project written mostly, or completely in-house (ex. invoicer). Especially ones that are meant to be used as composables in eg. docker-compose.yml files within noma.
This applies to all code that's written externally, that we only provide a wrapper for (ex. bitcoind, lnd).
That also means that subsequent releases of 0.0.patch versions change the content of the directory, while releases of new 0.minor.0 versions should create a new directory.
Using a variant might be a viable approach, but perhaps for smaller changes an in-place Dockerfile can be created and built by the users.
This defines a set of rules to keep in mind while writing, and within a Dockerfile.
Meaning: each should have sane defaults, and always allow for a simple docker build . right after git clone. Image built by default should target host architecture, and be locally runnable after build.
3.4.1. maintainer="" for the first/primary maintainer, and maintainer.<n>="" for all subsequent ones
Example:
LABEL maintainer="Dat Guy <[email protected]>"
LABEL maintainer.1="Dat Otha Guy <[email protected]>"NOTE: For external code commit should be set to the commit of our repository, specifically the one that triggered the automated build.
3.5. Projects targeting Go 1.13 and above, MAY build the same binaries twice using different bases, and only proceed if output binaries are identical
3.11. CMD should only be set for de-facto standard flags, or ones that are required for the image to run
Examples:
# de-facto standard interfaces for ZMQ on Bitcoind
CMD ["-zmqpubrawblock=tcp://0.0.0.0:28332", "-zmqpubrawtx=tcp://0.0.0.0:28333"]
# required config path (if invoicer wouldn't specify default config within):
ENTRYPOINT ["/bin/invoicer"]
CMD ["-config", "~/.lncm/invoicer.conf"]
3.12. Should contain as many comments as necessary for even novices to understand/be able to Google it
Example:
ENV BUILDFILE_HASH=a981094129632db17661613fe9d20e0e6b15aa498c65355e2088699b24c97f10
COPY ./build.sh .
# Verify that the build file is what's expected
RUN echo "${BUILDFILE_HASH} build.sh" | sha256sum -cThis defines how the source code of the projects should be tagged for release.
Valid examples:
v0.0.1
v0.18.1-nowallet
v0.17.0.1
v0.5.0+build666
v0.19.0-nowallet+build3
Examples:
- base Alpine image updated
- fix of a bug in build-process code
- optimizations to the final image applied
- version of
qemuis changed
This defines how already built images should be tagged for distribution.
Note: Getting short-tag recommendations on Github Actions can be simplified by using: https://github.com/meeDamian/tag-suggestions
This defines how alternative flavors/variants should be handled.
Example (create): To create a monitoring variant for 0.8/ version of lnd:
-
Make sure all prior changes are committed/stashed/deleted within
0.8/ -
Apply variant-specific changes to files
-
Create
.patchfile using sth like:git diff --no-prefix --relative=0.8/ > 0.8/variant-monitoring.patch -
Add & commit
0.8/variant-monitoring.patch -
Un-apply all variant changes with ex:
git checkout -- ., orgit restore .
Example (apply): Later, to build said variant the patch can be applied with:
patch < variant-monitoring.patch` can be used.
Click to see variant-monitoring.patch
diff --git Dockerfile Dockerfile
index c3f2274..91b48fa 100644
--- Dockerfile
+++ Dockerfile
@@ -147,8 +147,11 @@ COPY --from=cross-check /bin/lncli /bin/
# Define a root volume for data persistence.
VOLUME /root/.lnd
-# Expose lnd ports (rest, p2p, rpc respectively).
-EXPOSE 8080 9735 10009
+# Expose lnd ports (rest, monitoring, p2p, rpc respectively).
+EXPOSE 8080 8989 9735 10009
# Specify the start command and entrypoint as the lnd daemon.
ENTRYPOINT ["lnd"]
+
+# Okay to hardcode them here, as it's in a variant that specifically wants Prometheus
+CMD ["--prometheus.enable", "--prometheus.listen=0.0.0.0:8989"]
diff --git build.sh build.sh
index 3da6714..0f73bc8 100755
--- build.sh
+++ build.sh
@@ -43,6 +43,9 @@ TAGS="autopilotrpc invoicesrpc walletrpc routerrpc watchtowerrpc"
# TODO: Check if still needed after Go v1.14 release
TAGS="${TAGS} osusergo netgo static_build"
+# Added by yours truly (@lncm) to enable monitoring
+TAGS="${TAGS} monitoring"
+
build() {
binary_name=$1
extra_tags=$2More on howto: https://stackoverflow.com/questions/3418277/how-to-apply-git-diff-patch-without-git-installed
Example:
git push origin v0.19.0-nowallet- If
0.19/variant-nowallet.patchexists, apply it - Carry on as usual
This defines how the Automated-builds system should behave.
NOTE: For Github Actions https://github.com/meeDamian/sync-readme can be used to simplify the process