Run this command in the directory where docker-compose.yml
is located in order to run the Nextcloud cron job:
docker-compose exec -u www-data nextcloud php cron.php
Run this command in the directory where docker-compose.yml
is located in order to run the Nextcloud cron job:
docker-compose exec -u www-data nextcloud php cron.php
Note: I have not updated this config to use the xl
or xl-single
storage backends, hence the version is locked at RELEASE.2022-10-24T18-35-07Z
The following config works by using two domains: minio.mydomain.com
and console.minio.mydomain.com
.
For the basic Traefik setup this is based on, see Simple Traefik docker-compose setup with Lets Encrypt Cloudflare DNS-01 & TLS-ALPN-01 & HTTP-01 challenges. Regarding this setup, the important part is to enabled the docker autodiscovery and defining the certificate resolve (we’re using the ALPN resolver).
Be sure to choose a random MINIO_ROOT_PASSWORD
!
version: '3.5' services: minio: image: quay.io/minio/minio:RELEASE.2022-10-24T18-35-07Z command: server --console-address ":9001" /data volumes: - ./data:/data - ./config:/root/.minio environment: - MINIO_ROOT_USER=minioadmin - MINIO_ROOT_PASSWORD=uikui5choRith0ZieV2zohN5aish5r - MINIO_DOMAIN=minio.mydomain.com - MINIO_SERVER_URL=https://minio.mydomain.com - MINIO_BROWSER_REDIRECT_URL=https://console.minio.mydomain.com labels: - "traefik.enable=true" # Console - "traefik.http.routers.minio-console.rule=Host(`console.minio.mydomain.com`)" - "traefik.http.routers.minio-console.entrypoints=websecure" - "traefik.http.routers.minio-console.tls.certresolver=alpn" - "traefik.http.routers.minio-console.service=minio-console" - "traefik.http.services.minio-console.loadbalancer.server.port=9001" # APi - "traefik.http.routers.minio.rule=Host(`minio.mydomain.com`)" - "traefik.http.routers.minio.entrypoints=websecure" - "traefik.http.routers.minio.tls.certresolver=alpn" - "traefik.http.routers.minio.service=minio" - "traefik.http.services.minio.loadbalancer.server.port=9000"
Traefik does not load some of your services and you see an error message like the following one:
traefik_1 | time="2022-03-27T15:22:05Z" level=error msg="Could not define the service name for the router: too many services" routerName=myapp providerName=docker
with a docker label config with multiple routers like this:
labels: - "traefik.enable=true" - "traefik.http.routers.myapp-console.rule=Host(`console.myapp.mydomain.com`)" - "traefik.http.routers.myapp-console.entrypoints=websecure" - "traefik.http.routers.myapp-console.tls.certresolver=alpn" - "traefik.http.services.myapp-console.loadbalancer.server.port=9001" # - "traefik.http.routers.myapp.rule=Host(`myapp.mydomain.com`)" - "traefik.http.routers.myapp.entrypoints=websecure" - "traefik.http.routers.myapp.tls.certresolver=cloudflare-techoverflow" - "traefik.http.routers.myapp.tls.domains[0].main=mydomain.com" - "traefik.http.routers.myapp.tls.domains[0].sans=*.mydomain.com" - "traefik.http.services.myapp.loadbalancer.server.port=9000"
The basic issue here is that you have multiple routers defined for a single docker container and Traefik does not know which http.services
belongs to which http.routers
!
In order to fix this, explicitly tell traefik for each router what service it should use like this:
- "traefik.http.routers.myapp-console.service=myapp-console"
labels: - "traefik.enable=true" - "traefik.http.routers.myapp-console.rule=Host(`console.myapp.mydomain.com`)" - "traefik.http.routers.myapp-console.entrypoints=websecure" - "traefik.http.routers.myapp-console.tls.certresolver=alpn" - "traefik.http.routers.myapp-console.service=myapp-console" - "traefik.http.services.myapp-console.loadbalancer.server.port=9001" # - "traefik.http.routers.myapp.rule=Host(`myapp.mydomain.com`)" - "traefik.http.routers.myapp.entrypoints=websecure" - "traefik.http.routers.myapp.tls.certresolver=cloudflare-techoverflow" - "traefik.http.routers.myapp.tls.domains[0].main=mydomain.com" - "traefik.http.routers.myapp.tls.domains[0].sans=*.mydomain.com" - "traefik.http.routers.myapp.service=myapp" - "traefik.http.services.myapp.loadbalancer.server.port=9000"
I use the following docker-compose.yml
service:
version: '3.5' services: postgres: image: postgres restart: unless-stopped volumes: - ./pg_data:/var/lib/postgresql/data environment: - POSTGRES_PASSWORD=${POSTGRES_PASSWORD} - POSTGRES_DB=${POSTGRES_DB} - POSTGRES_USER=${POSTGRES_USER}
With the following .env
:
POSTGRES_DB=headscale POSTGRES_USER=headscale POSTGRES_PASSWORD=vah2phuen3shesahc6Jeenaechecee
Using .env
has the huge advantage that other services like my backup script can access the configuration in a standardized manner using environment variables.
I have the following docker-compose.yml
service:
version: '3.5' services: postgres: image: postgres restart: unless-stopped volumes: - ./pg_data:/var/lib/postgresql/data environment: - POSTGRES_PASSWORD=${POSTGRES_PASSWORD} - POSTGRES_DB=${POSTGRES_DB} - POSTGRES_USER=${POSTGRES_USER}
With the following .env
:
POSTGRES_DB=headscale POSTGRES_USER=headscale POSTGRES_PASSWORD=vah2phuen3shesahc6Jeenaechecee
Given that setup, I run pg_dump
like this:
source .env && docker-compose exec postgres pg_dump -U${POSTGRES_USER} > pgdump-$(date +%F_%H-%M-%S).sql
I use this in git repositories to ease the deployment process
#!/bin/bash # This script installs and enables/starts a systemd service # It also installs the service file export NAME=MyService cat >/etc/systemd/system/${NAME}.service <<EOF # TODO Copy & paste the systemd .service file here EOF # Enable and start service systemctl enable --now ${NAME}.service
The following example automatically installs a docker-compose
systemd .service:
#!/bin/bash # This script installs and enables/starts a systemd service # It also installs the service file export NAME=MyService cat >/etc/systemd/system/${NAME}.service <<EOF [Unit] Description=${NAME} Requires=docker.service After=docker.service [Service] Restart=always User=root Group=docker WorkingDirectory=$(pwd) # Shutdown container (if running) before unit is being started ExecStartPre=$(which docker-compose) -f docker-compose.yml down # Start container when unit is started ExecStart=$(which docker-compose) -f docker-compose.yml up # Stop container when unit is stopped ExecStop=$(which docker-compose) -f docker-compose.yml down [Install] WantedBy=multi-user.target EOF # Enable and start service systemctl enable --now ${NAME}.service
Any time I was trying to transfer a project in my docker-hosted gitlab instance. the transfer failed with error 500
and I was presented with the following error log:
==> /var/log/gitlab/gitlab-rails/production.log <== URI::InvalidURIError (query conflicts with opaque): lib/container_registry/client.rb:84:in `repository_tags' app/models/container_repository.rb:94:in `manifest' app/models/container_repository.rb:98:in `tags' app/models/container_repository.rb:118:in `has_tags?' app/models/project.rb:2890:in `has_root_container_repository_tags?' app/models/project.rb:1037:in `has_container_registry_tags?' app/services/projects/transfer_service.rb:61:in `transfer' app/services/projects/transfer_service.rb:35:in `execute' app/controllers/projects_controller.rb:120:in `transfer' app/controllers/application_controller.rb:490:in `set_current_admin' lib/gitlab/session.rb:11:in `with_session' app/controllers/application_controller.rb:481:in `set_session_storage' lib/gitlab/i18n.rb:105:in `with_locale' lib/gitlab/i18n.rb:111:in `with_user_locale' app/controllers/application_controller.rb:475:in `set_locale' app/controllers/application_controller.rb:469:in `set_current_context' lib/gitlab/metrics/elasticsearch_rack_middleware.rb:16:in `call' lib/gitlab/middleware/rails_queue_duration.rb:33:in `call' lib/gitlab/middleware/speedscope.rb:13:in `call' lib/gitlab/request_profiler/middleware.rb:17:in `call' lib/gitlab/database/load_balancing/rack_middleware.rb:23:in `call' lib/gitlab/metrics/rack_middleware.rb:16:in `block in call' lib/gitlab/metrics/web_transaction.rb:46:in `run' lib/gitlab/metrics/rack_middleware.rb:16:in `call' lib/gitlab/jira/middleware.rb:19:in `call' lib/gitlab/middleware/go.rb:20:in `call' lib/gitlab/etag_caching/middleware.rb:21:in `call' lib/gitlab/middleware/multipart.rb:173:in `call' lib/gitlab/middleware/read_only/controller.rb:50:in `call' lib/gitlab/middleware/read_only.rb:18:in `call' lib/gitlab/middleware/same_site_cookies.rb:27:in `call' lib/gitlab/middleware/handle_malformed_strings.rb:21:in `call' lib/gitlab/middleware/basic_health_check.rb:25:in `call' lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call' lib/gitlab/middleware/request_context.rb:21:in `call' lib/gitlab/middleware/webhook_recursion_detection.rb:15:in `call' config/initializers/fix_local_cache_middleware.rb:11:in `call' lib/gitlab/middleware/compressed_json.rb:26:in `call' lib/gitlab/middleware/rack_multipart_tempfile_factory.rb:19:in `call' lib/gitlab/middleware/sidekiq_web_static.rb:20:in `call' lib/gitlab/metrics/requests_rack_middleware.rb:75:in `call' lib/gitlab/middleware/release_env.rb:13:in `call'
This error seems to occur if you had a docker registry configured in previous gitlab versions (a legacy docker repository) but doesn’t disappear even after deconfiguring the registry.
In order to fix it, I logged into the container using
docker-compose exec gitlab /bin/bash
and edited /opt/gitlab/embedded/service/gitlab-rails/app/models/project.rb
using
vi /opt/gitlab/embedded/service/gitlab-rails/app/models/project.rb
where on line 2890
you can find the following function:
## # This method is here because of support for legacy container repository # which has exactly the same path like project does, but which might not be # persisted in `container_repositories` table. # def has_root_container_repository_tags? return false unless Gitlab.config.registry.enabled ContainerRepository.build_root_repository(self).has_tags? end
We just want Gitlab to ignore the repository stuff, so we insert return false
after the return false unless Gitlab.config.registry.enabled
line:
## # This method is here because of support for legacy container repository # which has exactly the same path like project does, but which might not be # persisted in `container_repositories` table. # def has_root_container_repository_tags? return false unless Gitlab.config.registry.enabled return false ContainerRepository.build_root_repository(self).has_tags? end
to fake Gitlab into thinking that repository does not have any legacy registries. After that, save the file and
sudo gitlab-ctl restart
after which you should be able to transfer your repositories just fine.
When starting docker on a VM that got suddenly turned off before during a power outage, the docker daemon failed to start up with the following error log:
Jan 05 15:15:14 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:14.946815577Z" level=info msg="Starting up" Jan 05 15:15:14 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:14.947842629Z" level=info msg="detected 127.0.0.53 nameserver, assuming systemd-resolved, so using resolv.conf: /run/systemd/resolve/resolv.conf" Jan 05 15:15:14 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:14.949500623Z" level=info msg="parsed scheme: \"unix\"" module=grpc Jan 05 15:15:14 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:14.949617127Z" level=info msg="scheme \"unix\" not registered, fallback to default scheme" module=grpc Jan 05 15:15:14 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:14.949705114Z" level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock <nil> 0 <nil>}] <nil> <nil>}" module=grpc Jan 05 15:15:14 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:14.949776371Z" level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc Jan 05 15:15:14 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:14.950747679Z" level=info msg="parsed scheme: \"unix\"" module=grpc Jan 05 15:15:14 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:14.950788173Z" level=info msg="scheme \"unix\" not registered, fallback to default scheme" module=grpc Jan 05 15:15:14 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:14.950806216Z" level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock <nil> 0 <nil>}] <nil> <nil>}" module=grpc Jan 05 15:15:14 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:14.950815090Z" level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:15.012683899Z" level=info msg="[graphdriver] using prior storage driver: overlay2" Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:15.027806434Z" level=warning msg="Docker could not enable SELinux on the host system" Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:15.176098505Z" level=info msg="Loading containers: start." Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: time="2022-01-05T15:15:15.728503609Z" level=info msg="Removing stale sandbox 22e03a9f65217fa0ce1603fa1d6326b7bf412777be94e930b02dbe6554549084 (154aa4bd403045e229b39cc4dda1d16a72b45d18671cab7c993bff4eaee9c2c9)" Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: panic: assertion failed: write: circular dependency occurred Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: goroutine 1 [running]: Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/go.etcd.io/bbolt._assert(...) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/go.etcd.io/bbolt/db.go:1172 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/go.etcd.io/bbolt.(*node).write(0xc0001e16c0, 0xc001381000) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/go.etcd.io/bbolt/node.go:233 +0x3c5 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/go.etcd.io/bbolt.(*node).spill(0xc0001e16c0, 0xc0012da078, 0x1) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/go.etcd.io/bbolt/node.go:374 +0x225 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/go.etcd.io/bbolt.(*node).spill(0xc0001e1650, 0xc000fefaa0, 0xc000d9dc50) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/go.etcd.io/bbolt/node.go:346 +0xbc Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/go.etcd.io/bbolt.(*Bucket).spill(0xc000d6f180, 0xc000fefa00, 0xc000d9de40) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/go.etcd.io/bbolt/bucket.go:570 +0x49a Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/go.etcd.io/bbolt.(*Bucket).spill(0xc000fca2b8, 0x310b759f, 0x55dfe7bf17e0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/go.etcd.io/bbolt/bucket.go:537 +0x3f6 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/go.etcd.io/bbolt.(*Tx).Commit(0xc000fca2a0, 0x0, 0x0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/go.etcd.io/bbolt/tx.go:160 +0xe8 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/go.etcd.io/bbolt.(*DB).Update(0xc000d6bc00, 0xc000d9e078, 0x0, 0x0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/go.etcd.io/bbolt/db.go:701 +0x105 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/docker/libkv/store/boltdb.(*BoltDB).AtomicPut(0xc000a862d0, 0xc000fd32d0, 0x65, 0xc000d46300, 0x179, 0x180, 0xc000fef890, 0x0, 0x55dfe5407900, 0x0, ...) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/docker/libkv/store/boltdb/boltdb.go:371 +0x225 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/docker/libnetwork/datastore.(*datastore).PutObjectAtomic(0xc000c3bbc0, 0x55dfe6bd1398, 0xc000efad20, 0x0, 0x0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/docker/libnetwork/datastore/datastore.go:415 +0x3ca Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/docker/libnetwork/drivers/bridge.(*driver).storeUpdate(0xc0000c3c00, 0x55dfe6bd1398, 0xc000efad20, 0x0, 0x0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/docker/libnetwork/drivers/bridge/bridge_store.go:106 +0x6e Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/docker/libnetwork/drivers/bridge.(*driver).RevokeExternalConnectivity(0xc0000c3c00, 0xc000f19d80, 0x40, 0xc00111c300, 0x40, 0x0, 0x0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/docker/libnetwork/drivers/bridge/bridge.go:1405 +0x1f1 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/docker/libnetwork.(*endpoint).sbLeave(0xc000d41e40, 0xc000f63200, 0x1, 0x0, 0x0, 0x0, 0x0, 0xc001b91ce0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/docker/libnetwork/endpoint.go:751 +0x1326 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/docker/libnetwork.(*endpoint).Delete(0xc000d41b80, 0xc000f19d01, 0x0, 0x0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/docker/libnetwork/endpoint.go:842 +0x374 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/docker/libnetwork.(*sandbox).delete(0xc000f63200, 0x1, 0x55dfe61ee216, 0x1e) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/docker/libnetwork/sandbox.go:229 +0x191 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/docker/libnetwork.(*controller).sandboxCleanup(0xc000432a00, 0x0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/docker/libnetwork/sandbox_store.go:278 +0xdae Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/docker/libnetwork.New(0xc0000c3b80, 0x9, 0x10, 0xc000878090, 0xc001e69e60, 0xc0000c3b80, 0x9) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/docker/libnetwork/controller.go:248 +0x726 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/daemon.(*Daemon).initNetworkController(0xc00000c1e0, 0xc00021a000, 0xc001e69e60, 0xc000151270, 0xc00000c1e0, 0xc000686a10, 0xc001e69e60) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/daemon/daemon_unix.go:855 +0xac Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/daemon.(*Daemon).restore(0xc00000c1e0, 0xc00045c4c0, 0xc00023e2a0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/daemon/daemon.go:490 +0x52c Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/daemon.NewDaemon(0x55dfe6bad710, 0xc00045c4c0, 0xc00021a000, 0xc000878090, 0x0, 0x0, 0x0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/daemon/daemon.go:1150 +0x2c1d Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: main.(*DaemonCli).start(0xc000b62720, 0xc00009a8a0, 0x0, 0x0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/cmd/dockerd/daemon.go:195 +0x785 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: main.runDaemon(...) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/cmd/dockerd/docker_unix.go:13 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: main.newDaemonCommand.func1(0xc0000bc2c0, 0xc0000b2000, 0x0, 0xc, 0x0, 0x0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/cmd/dockerd/docker.go:34 +0x7d Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/spf13/cobra.(*Command).execute(0xc0000bc2c0, 0xc00011caa0, 0xc, 0xc, 0xc0000bc2c0, 0xc00011caa0) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/spf13/cobra/command.go:850 +0x472 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc0000bc2c0, 0x0, 0x0, 0x10) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/spf13/cobra/command.go:958 +0x375 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: github.com/docker/docker/vendor/github.com/spf13/cobra.(*Command).Execute(...) Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/vendor/github.com/spf13/cobra/command.go:895 Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: main.main() Jan 05 15:15:15 CoreOS-Haar dockerd[5333]: /builddir/build/BUILD/moby-20.10.11/src/github.com/docker/docker/cmd/dockerd/docker.go:97 +0x185 Jan 05 15:15:15 CoreOS-Haar systemd[1]: docker.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
First, try moving /var/lib/docker/network/files/local-kv.db
:
sudo mv /var/lib/docker/network/files/local-kv.db /opt/old-docker-local-kv.db
and then restarting docker
using e.g. sudo systemctl restart docker,
which worked for many users on GitHub.
Only if that does not work, try the following brute-force method!
Move the /var/lib/docker
directory to a new location for backup, after which docker was able to start up again:
sudo mv /var/lib/docker /opt/old-var-lib-docker
This is a pretty brute-force method of doing that but for me it worked totally fine since my setup did not use volumes but local directories. In case you are actively using volumes, you might need to restore the volumes from /opt/old-var-lib-docker
manually!
In order to install Uptime-Kuma, first create a directory for the service to reside in. In this example, we’ll use /opt/uptimekuma
Note that at the moment UptimeKuma only supports one user, so if you need multiple users, you need to create multiple instances of Uptime-Kuma. Fortunately, this is extremely easy using docker-compose.
Now we will create docker-compose.yml
version: '3' services: kuma: image: 'louislam/uptime-kuma:1' ports: - '17958:3001' volumes: - './uptimekuma_data:/app/data'
This will listen on port 17958
. You can choose any port you want here, just make sure to choose different ports when running different instances of uptime-kuma.
Now you can use our script from Create a systemd service for your docker-compose project in 10 seconds to automatically start Uptime-Kuma on boot (and start it immediately):
curl -fsSL https://techoverflow.net/scripts/create-docker-compose-service.sh | sudo bash /dev/stdin
Now access https://<IP of controller>:17958
(or your custom HTTP port) to get started with the Uptime-Kuma setup.
Also see this variant with Traefik reverse proxy config: XenOrchestra docker-compose setup with Traefik labels
Create a directory such as /opt/xenorchestra
and create docker-compose.yml
:
version: '3' services: xen-orchestra: restart: unless-stopped image: ronivay/xen-orchestra:latest container_name: xen-orchestra network_mode: host stop_grace_period: 1m environment: - HTTP_PORT=1780 cap_add: - SYS_ADMIN security_opt: - apparmor:unconfined volumes: - ./xo-data:/var/lib/xo-server - ./redis-data:/var/lib/redis
You can choose any HTTP port you want using HTTP_PORT=1780
. In this case, we opted for using network_mode: host
to bypass the docker networking, since XenOrchestra seems to work better with full network access instead of the container having an own IP.
Now you can use our script from Create a systemd service for your docker-compose project in 10 seconds to automatically start XenOrchestra on boot (and start it immediately):
curl -fsSL https://techoverflow.net/scripts/create-docker-compose-service.sh | sudo bash /dev/stdin
Now access https://<IP of controller>:1780
(or your custom HTTP port) to get started with the XO setup.
Updated 2022-12-24: Added --bind_ip 127.0.0.1
to prevent remote MongoDB access in context with network_mode: host
. Thanks Matt Johnson for the suggestion 🙂
This setup runs both MongoDB and unifi using network_mode: host
, this is why we are running MongoDB on a nonstandard port (so it will not interfere with other MongoDB instances). This has the huge benefit of allowing direct Layer 2 network access allowing L2 access point adoption.
Create a directory such as /opt/unifi
and create docker-compose.yml
version: '2.3' services: mongo: image: mongo:3.6 network_mode: host restart: always volumes: - ./mongo_db:/data/db - ./mongo/dbcfg:/data/configdb command: mongod --bind_ip 127.0.0.1 --port 29718 controller: image: "jacobalberty/unifi:latest" depends_on: - mongo init: true network_mode: host restart: always volumes: - ./unifi_dir:/unifi - ./unifi_data:/unifi/data - ./unifi_log:/unifi/log - ./unifi_cert:/unifi/cert - ./unifi_init:/unifi/init.d - ./unifi_run:/var/run/unifi - ./unifi_backup:/unifi/data/backup environment: - DB_URI=mongodb://localhost:29718/unifi - STATDB_URI=mongodb://localhost:29718/unifi_stat - DB_NAME=unifi logs: image: bash depends_on: - controller command: bash -c 'tail -F /unifi/log/*.log' restart: always volumes: - ./unifi_log:/unifi/log
Now create the directories with the correct permissions:
mkdir -p unifi_backup unifi_cert unifi_data unifi_dir unifi_init unifi_log unifi_run chown -R 999:999 unifi_backup unifi_cert unifi_data unifi_dir unifi_init unifi_log unifi_run
Now you can use our script from Create a systemd service for your docker-compose project in 10 seconds to automatically start the controller on boot (and start it immediately):
curl -fsSL https://techoverflow.net/scripts/create-docker-compose-service.sh | sudo bash /dev/stdin
Now access https://<IP of controller>:8443
to get started with the setup or import a backup.
Your Unifi controller running on docker or docker-compose shows log messages like
controller_1 | [2021-12-29 17:37:26,396] <docker-entrypoint> Starting unifi controller service. controller_1 | /usr/local/bin/docker-entrypoint.sh: line 97: /unifi/data/system.properties: Permission denied controller_1 | /usr/local/bin/docker-entrypoint.sh: line 97: /unifi/data/system.properties: Permission denied controller_1 | /usr/local/bin/docker-entrypoint.sh: line 97: /unifi/data/system.properties: Permission denied controller_1 | /usr/local/bin/docker-entrypoint.sh: line 97: /unifi/data/system.properties: Permission denied
on startup.
Fix the permissions of the directory mounted. I have listed
volumes: - ./unifi_data:/unifi/data
in my docker-compose.yml
.
Fix the permissions by
sudo chown -R 999:999 unifi_data
First, create a directory where HomeAssistant will reside. I use /opt/homeassistant
.
Create docker-compose.yml
:
version: '3.5' services: homeassistant: container_name: homeassistant restart: unless-stopped image: ghcr.io/home-assistant/home-assistant:stable network_mode: host privileged: true environment: - TZ=Europe/Berlin volumes: - ./homeassistant_config:/config depends_on: - mosquitto mosquitto: image: eclipse-mosquitto network_mode: host volumes: - ./mosquitto_conf:/mosquitto/config - ./mosquitto_data:/mosquitto/data - ./mosquitto_log:/mosquitto/log
Now start homeassistant so it creates the default config files:
docker-compose up
Once you see
homeassistant | [services.d] done.
Press Ctrl+C to abort.
Now we’ll create the Mosquitto MQTT server config file in mosquitto_conf/mosquitto.conf
:
persistence true persistence_location /mosquitto/data/ log_dest file /mosquitto/log/mosquitto.log listener 1883 ## Authentication ## allow_anonymous false password_file /mosquitto/config/mosquitto.passwd
Now create the mosquitto password file and fix the permissions using
touch mosquitto_conf/mosquitto.passwd chown -R 1883:1883 mosquitto_conf
We can now start create the homeassistant
mosquitto user using
docker-compose run mosquitto mosquitto_passwd -c /mosquitto/config/mosquitto.passwd homeassistant
Enter a random password that will be used for the homeassistant
user
Now we can edit the homeassistant config homeassistant_config/configuration.yml
. This is my config – ensure to insert the random MQTT password we used before instead of ep2ooy8di3avohn1Ahm6eegheiResh
:
# Configure a default setup of Home Assistant (frontend, api, etc) default_config: http: use_x_forwarded_for: true trusted_proxies: - 127.0.0.1 ip_ban_enabled: true login_attempts_threshold: 5 mqtt: broker: "127.0.0.1" username: "homeassistant" password: "ep2ooy8di3avohn1Ahm6eegheiResh" # Text to speech tts: - platform: google_translate group: !include groups.yaml automation: !include automations.yaml script: !include scripts.yaml scene: !include scenes.yaml
Now we can start the server using
docker-compose up
You can also use our script to generate a systemd service to autostart the docker-compose config on boot:
curl -fsSL https://techoverflow.net/scripts/create-docker-compose-service.sh | sudo bash /dev/stdin
Now login to the web interface on port 8123
and configure your HomeAssistant!
My docker-compose
-based Caddy setup re-created the container and hence created a new docker volume with only the autosave.json
whenever it was restarted. Since it was auto-restarted once a minute, this led do over 70000 volumes piling up in /var/lib/docker/volumes
.
The Caddy log shows that Caddy is creating /config/caddy/autosave.json
:
mycaddy_1 | {"level":"info","ts":1637877640.7375677,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
I fixed this by mapping /config/caddy
to a local directory:
- ./caddy_data:/config/caddy/
docker-compose.yml
example:version: '3.5' services: mycaddy: image: 'caddy:2.4.6-alpine' volumes: - ./caddy_data:/config/caddy/ - ./static:/usr/share/caddy - ./Caddyfile:/etc/caddy/Caddyfile ports: - 19815:80
When mosquitto exits with code 13
such as a in a docker
based setup, you will often see not error messsage:
Attaching to mosquitto_mosquitto_1 mosquitto_mosquitto_1 exited with code 13
However, there will be an error message in mosquitto.log
. So, ensure that you have configured a log_dest file
in your mosquitto.conf
such as:
log_dest file /mosquitto/log/mosquitto.log
and check that file. In my case it showed these error messages:
1637860284: mosquitto version 2.0.14 starting 1637860284: Config loaded from /mosquitto/config/mosquitto.conf. 1637860284: Error: Unable to open pwfile "/mosquitto/conf/mosquitto.passwd". 1637860284: Error opening password file "/mosquitto/conf/mosquitto.passwd".
In my case, the path of the password file was mis-spelled (conf
instead of config
)
Note that you need to create the password file in order for mosquitto to start up!
See How to setup standalone mosquitto MQTT broker using docker-compose for example commands on how to create the user and the password file
Your Docker container running home-assistant always exits immediately after starting up, with the log being similar to this:
$ docker-compose up Recreating homeassistant ... done Attaching to homeassistant homeassistant | [s6-init] making user provided files available at /var/run/s6/etc...exited 0. homeassistant | [s6-init] ensuring user provided files have correct perms...exited 0. homeassistant | [fix-attrs.d] applying ownership & permissions fixes... homeassistant | [fix-attrs.d] done. homeassistant | [cont-init.d] executing container initialization scripts... homeassistant | [cont-init.d] done. homeassistant | [services.d] starting services homeassistant | [services.d] done. homeassistant | [finish] process exit code 256 homeassistant | [finish] process received signal 15 homeassistant | [cont-finish.d] executing container finish scripts... homeassistant | [cont-finish.d] done. homeassistant | [s6-finish] waiting for services. homeassistant | [s6-finish] sending all processes the TERM signal. homeassistant | [s6-finish] sending all processes the KILL signal and exiting. homeassistant exited with code 0
You need to start the container with --privileged=true
if using docker
directly to start up the service, or use privileged: true
if using docker-compose
.
Here’s an example of a working docker-compose.yml
file:
version: '3.5' services: homeassistant: container_name: homeassistant restart: unless-stopped image: ghcr.io/home-assistant/home-assistant:stable network_mode: host privileged: true environment: - TZ=Europe/Berlin volumes: - ./config:/config
https://techoverflow.net/wp-admin/post-new.php#category-all
If your MariaDB / MySQL root password is stored in .env
, use this command:
source .env && docker-compose exec mariadb mysqlcheck -uroot -p$MARIADB_ROOT_PASSWORD --auto-repair --optimize --all-databases
You can also directly use the root password in the command:
docker-compose exec mariadb mysqlcheck -uroot -phoox8AiFahuniPaivatoh2iexighee --auto-repair --optimize --all-databases
In our previous post How to run Collabora office for Nextcloud using docker-compose we investigated how to configure your Collabora office server using docker-compose.yml
.
If you want to use multiple domains, you need to change this line in .env
:
COLLABORA_DOMAIN=collabora.mydomain.com
to
COLLABORA_DOMAIN=https://nextcloud.mydomain.com:443,https://nextcloud.myseconddomain.com:443
If you want to use multiple domains, you need to change this line in .env
:
COLLABORA_DOMAIN=collabora.mydomain.com
By reading the source code I found out that COLLABORA_DOMAIN
is interpreted as a regular expression. Therefore you can use a (...|...|...)
syntax.
COLLABORA_DOMAIN=(nextcloud.mydomain.com|nextcloud.myseconddomain.com)
After that, restart collabora.
Create this docker-compose.yml
, e.g. in /opt/collabora-mydomain
:
version: '3' services: code: image: collabora/code:latest restart: always environment: - password=${COLLABORA_PASSWORD} - username=${COLLABORA_USERNAME} - domain=${COLLABORA_DOMAIN} - extra_params=--o:ssl.enable=true ports: - 9980:9980
Now create this .env
with the configuration. You need to change the password and the domain!
COLLABORA_USERNAME=admin COLLABORA_PASSWORD=veecheit0Phophiesh1fahPah0Wue3 COLLABORA_DOMAIN=collabora.mydomain.com
Now you can create a systemd service to autostart by using our script from Create a systemd service for your docker-compose project in 10 seconds.
Run from inside your directory (e.g. /opt/collabora-mydomain
)
curl -fsSL https://techoverflow.net/scripts/create-docker-compose-service.sh | sudo bash /dev/stdin
Now you need to configure your reverse proxy to point to port 9980
. Here’s an example nginx
config:
server { server_name collabora.mydomain.com; access_log /var/log/nginx/collabora.mydomain.com.access_log; error_log /var/log/nginx/collabora.mydomain.com.error_log info; location / { proxy_pass https://127.0.0.1:9980; proxy_http_version 1.1; proxy_read_timeout 3600s; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; add_header X-Frontend-Host $host; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; } listen [::]:80; # managed by Certbot }
Now open your browser and open collabora.mydomain.com
. If collabora is running correctly, you should see:
OK
In Nextcloud, goto https://nextcloud.mydomain.com/settings/admin/richdocuments
and set the
https://admin:[email protected]
Ensure to use your custom password from .env
and your custom domain!
Click Save and you should see Collabora Online server is reachable
:
When using the official nextcloud
docker image, you will see a message like
Module php-imagick in this instance has no SVG support. For better compatibility it is recommended to install it.
on the system overview page
This is a bug in the docker image and will likely be resolved soon – in the meantime, we can just manually install the required library on the container:
docker-compose exec nextcloud apt -y update docker-compose exec nextcloud apt -y install libmagickcore-6.q16-6-extra
If you re-create the container, this change will be lost, but in my opinion it’s best to opt for a simple solution here and possible do it again once or twice as opposed to a permanent but much more labour-intensive procedure like updating the docker image and later migrating back to the official image.