This image has been deprecated and no updates (or support) may be available in future. Even though it is a container, it may or may not keep working as expected, use at your own risk.
Container for Alpine Linux + S6 + NGINX + Laverna Note-taking webapp
This image containerizes the prebuilt version of Laverna Note-taking static webapp.
Based on Alpine Linux (v3.10) from the nginx image image with NGINX and the Laverna static webapp files overlayed in it. Updated according to the Laverna/static-laverna (branch gh-pages).
latest tag is retagged from x86_64, so pulling without any tag fetches you that image. For any other architectures specify the tag for that architecture. e.g. for armv8 or aarch64 host it is alpine-laverna:aarch64.
non-x86_64 images used to contain the embedded qemu-user-static binary which has been redundant for a while, and is being deprecated starting with our Alpine Linux v3.22 base-image release, see qemu-user-static or the more recent binfmt instead for running multi-arch containers.
If you want to run images built for other architectures on the same host (e.g. a x86_64 machine), you will need to have the specific binary format support configured on your host machine before running the image (otherwise you get an exec format error). Here's how,
For recent images, we can use tonistiigi's binfmtimage to register binary execution support for the target architecture, like the following,
However, that image (see qemu-user-static) seems to have fallen behind in updates, and with newer images the binfmt method is preferable.
Now images built for other architectures will also be executable. This is optional though, without the above, you can still run the image that is specifically made to support your host architecture.
Laverna is located at the endpoint /laverna/, with configurations at /config/www/laverna/ and data at /config/www/laverna/data/. Uploaded images go to /config/www/laverna/uploads.
These configurations are inherited from the nginx image:
Drop privileges to alpine whenever configured to. Respects PUID / PGID.
Binds to both http(80) and https(443). Publish whichever you need, or both.
Default configs setup a static site at / by copying /defaults/index.html at the webroot location /config/www/. Mount the /config/ locally to persist modifications (or your webapps). NGINX configs are at /config/nginx, and vhosts at /config/nginx/site-confs/.
4096bit Self-signed SSL certificate is generated in first run at /config/keys. Pass the runtime variable SSLSUBJECT with a valid info string to make your own.
.htpasswd is generated with default credentials admin/insecurebydefault at /config/keys/.htpasswd
Sets up a https and auth protected web location at /secure.
If you're proxying multiple containers at the same host, or reverse proxying multiple hosts at the same container, you may need to add --net=host and/or add entries in your firewall to allow traffic.
Stop the container with a timeout, (defaults to 2 seconds)
dockerstop-t2docker_laverna
Restart the container with
dockerrestartdocker_laverna
Removes the container, (always better to stop it first and -f only when needed most)
Feel free to clone (or fork) the repository and customize it for your own usage, build the image for yourself on your own systems, and optionally, push it to your own public (or private) repository.
Before we clone the /repository, we must have Git, GNU make, and Docker (optionally, with buildx plugin for multi-platform images) setup on the machine. Also, for multi-platform annotations, we might require enabling experimental features of Docker.
Running the image creates a container and either starts a service (for service images) or provides a shell (can be either a root-shell or usershell) to execute commands in, depending on the image. We can run the image with
makerun
But if we just need a root-shell in the container without any fance pre-tasks (e.g. for debug or to test something bespoke), we can run bash in the container with --entrypoint /bin/bash. This is wrapped in the makefile as
makeshell
Nothing vs All vs Run vs Shell
By default, if make is run without any arguments, it calls the target all. In our case this is usually mapped to the target run (which in turn may be mapped to shell).
There may be more such targets defined as per the usage of the image. Check the makefile for more information.
If the build and test steps finish without any error, and we want to use the image on other machines, it is the next step push the image we built to a container image repository (like /hub), for that, run the push target with
makepush
If the built image targets another architecture then it is required to specify the ARCH parameter when pushing. e.g.
Maintained (or sometimes a lack thereof?) by WOAHBase.
Helped you save a bit of your valuable time and effort that is best spent doing stuff you actually enjoy? If you have some pocket-change to spare, kindly consider helping out.