This is page 10 of 22. Use http://codebase.md/id/docs/get_started/create/presentation_layout.html?lines=false&page={x} to view the full context.
# Directory Structure
```
├── .ci
│ ├── check-markdownfmt.sh
│ ├── check-metadata.sh
│ ├── check-pr-no-readme.sh
│ ├── check-required-files.sh
│ ├── check-short.sh
│ ├── check-ymlfmt.sh
│ └── get-markdownfmt.sh
├── .common-templates
│ ├── maintainer-community.md
│ ├── maintainer-docker.md
│ ├── maintainer-hashicorp.md
│ └── maintainer-influxdata.md
├── .dockerignore
├── .github
│ └── workflows
│ └── ci.yml
├── .template-helpers
│ ├── arches.sh
│ ├── autogenerated-warning.md
│ ├── compose.md
│ ├── generate-dockerfile-links-partial.sh
│ ├── generate-dockerfile-links-partial.tmpl
│ ├── get-help.md
│ ├── issues.md
│ ├── license-common.md
│ ├── template.md
│ ├── variant-alpine.md
│ ├── variant-default-buildpack-deps.md
│ ├── variant-default-debian.md
│ ├── variant-default-ubuntu.md
│ ├── variant-onbuild.md
│ ├── variant-slim.md
│ ├── variant-windowsservercore.md
│ ├── variant.md
│ └── variant.sh
├── adminer
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── aerospike
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── almalinux
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── alpine
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── alt
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── amazoncorretto
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── amazonlinux
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── api-firewall
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── arangodb
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── archlinux
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── backdrop
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── bash
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── bonita
│ ├── compose.yaml
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── buildpack-deps
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── busybox
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ ├── variant-glibc.md
│ ├── variant-musl.md
│ ├── variant-uclibc.md
│ └── variant.md
├── caddy
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo-120.png
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── cassandra
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── chronograf
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── cirros
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── clearlinux
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── clefos
│ ├── content.md
│ ├── deprecated.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── clickhouse
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── clojure
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── composer
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── convertigo
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── couchbase
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── couchdb
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── crate
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── dart
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── debian
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ ├── variant-slim.md
│ └── variant.md
├── docker
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ ├── variant-rootless.md
│ └── variant-windowsservercore.md
├── Dockerfile
├── drupal
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── variant-fpm.md
├── eclipse-mosquitto
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── eclipse-temurin
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── eggdrop
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── elasticsearch
│ ├── compose.yaml
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── variant-alpine.md
├── elixir
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── emqx
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── erlang
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── fedora
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── flink
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── fluentd
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── friendica
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── gazebo
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── gcc
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── generate-repo-stub-readme.sh
├── geonetwork
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ ├── variant-postgres.md
│ └── variant.md
├── get-categories.sh
├── ghost
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── golang
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ ├── variant-alpine.md
│ └── variant-tip.md
├── gradle
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── groovy
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── haproxy
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── haskell
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── variant-slim.md
├── haxe
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── hello-world
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── update.sh
├── hitch
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── httpd
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── hylang
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── ibm-semeru-runtimes
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── ibmjava
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── influxdb
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ ├── variant-data.md
│ └── variant-meta.md
├── irssi
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── jetty
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── joomla
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── jruby
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── julia
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── kapacitor
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── kibana
│ ├── compose.yaml
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── kong
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── krakend
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo-120.png
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── LICENSE
├── lightstreamer
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── liquibase
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── logstash
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── variant-alpine.md
├── mageia
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── mariadb
│ ├── compose.yaml
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── markdownfmt.sh
├── matomo
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── maven
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── mediawiki
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── memcached
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── metadata.json
├── metadata.sh
├── mongo
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── mongo-express
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── monica
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── mono
│ ├── content.md
│ ├── deprecated.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── mysql
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── nats
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── neo4j
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── neurodebian
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── nextcloud
│ ├── content.md
│ ├── deprecated.md
│ ├── github-repo
│ ├── license.md
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── nginx
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── variant-perl.md
├── node
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── notary
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── odoo
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── open-liberty
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── openjdk
│ ├── content.md
│ ├── deprecated.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ ├── variant-alpine.md
│ ├── variant-oracle.md
│ └── variant-slim.md
├── oraclelinux
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── variant-slim.md
├── orientdb
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── parallel-update.sh
├── percona
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── perl
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── photon
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── php
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ ├── variant-apache.md
│ ├── variant-cli.md
│ ├── variant-fpm.md
│ └── variant.md
├── php-zendserver
│ ├── content.md
│ ├── deprecated.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── phpmyadmin
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── plone
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── postfixadmin
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ ├── variant-apache.md
│ ├── variant-fpm-alpine.md
│ └── variant-fpm.md
├── postgres
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── push.pl
├── push.sh
├── pypy
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── python
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── variant-slim.md
├── r-base
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── rabbitmq
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── rakudo-star
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── README.md
├── redis
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── redmine
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── registry
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── rethinkdb
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── rocket.chat
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── rockylinux
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── ros
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── ruby
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── rust
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── sapmachine
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── satosa
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── scratch
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── silverpeas
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── solr
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── sonarqube
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── spark
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── spiped
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── storm
│ ├── compose.yaml
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── swift
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── swipl
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── teamspeak
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── telegraf
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── tomcat
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── tomee
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── traefik
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── variant-alpine.md
├── ubuntu
│ ├── content.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── unit
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── update.sh
├── varnish
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── websphere-liberty
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── wordpress
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ ├── variant-cli.md
│ └── variant-fpm.md
├── xwiki
│ ├── content.md
│ ├── get-help.md
│ ├── github-repo
│ ├── issues.md
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ └── README.md
├── ymlfmt.sh
├── yourls
│ ├── compose.yaml
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.svg
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── variant-fpm.md
├── znc
│ ├── content.md
│ ├── github-repo
│ ├── license.md
│ ├── logo.png
│ ├── maintainer.md
│ ├── metadata.json
│ ├── README-short.txt
│ ├── README.md
│ └── variant-slim.md
└── zookeeper
├── compose.yaml
├── content.md
├── github-repo
├── license.md
├── logo.png
├── maintainer.md
├── metadata.json
├── README-short.txt
└── README.md
```
# Files
--------------------------------------------------------------------------------
/ros/README.md:
--------------------------------------------------------------------------------
```markdown
<!--
********************************************************************************
WARNING:
DO NOT EDIT "ros/README.md"
IT IS AUTO-GENERATED
(from the other files in "ros/" combined with a set of templates)
********************************************************************************
-->
# Quick reference
- **Maintained by**:
[the Open Source Robotics Foundation](https://github.com/osrf/docker_images)
- **Where to get help**:
[the Docker Community Slack](https://dockr.ly/comm-slack), [Server Fault](https://serverfault.com/help/on-topic), [Unix & Linux](https://unix.stackexchange.com/help/on-topic), or [Stack Overflow](https://stackoverflow.com/help/on-topic)
# Supported tags and respective `Dockerfile` links
- [`noetic-ros-core`, `noetic-ros-core-focal`](https://github.com/osrf/docker_images/blob/b525e9ef659ce448db6150fd5407ef62b2c5b265/ros/noetic/ubuntu/focal/ros-core/Dockerfile)
- [`noetic-ros-base`, `noetic-ros-base-focal`, `noetic`](https://github.com/osrf/docker_images/blob/df19ab7d5993d3b78a908362cdcd1479a8e78b35/ros/noetic/ubuntu/focal/ros-base/Dockerfile)
- [`noetic-robot`, `noetic-robot-focal`](https://github.com/osrf/docker_images/blob/df19ab7d5993d3b78a908362cdcd1479a8e78b35/ros/noetic/ubuntu/focal/robot/Dockerfile)
- [`noetic-perception`, `noetic-perception-focal`](https://github.com/osrf/docker_images/blob/df19ab7d5993d3b78a908362cdcd1479a8e78b35/ros/noetic/ubuntu/focal/perception/Dockerfile)
- [`humble-ros-core`, `humble-ros-core-jammy`](https://github.com/osrf/docker_images/blob/b525e9ef659ce448db6150fd5407ef62b2c5b265/ros/humble/ubuntu/jammy/ros-core/Dockerfile)
- [`humble-ros-base`, `humble-ros-base-jammy`, `humble`](https://github.com/osrf/docker_images/blob/20e3ba685bb353a3c00be9ba01c1b7a6823c9472/ros/humble/ubuntu/jammy/ros-base/Dockerfile)
- [`humble-perception`, `humble-perception-jammy`](https://github.com/osrf/docker_images/blob/20d40c96b426b8956dec203e236abff2ec29b188/ros/humble/ubuntu/jammy/perception/Dockerfile)
- [`iron-ros-core`, `iron-ros-core-jammy`](https://github.com/osrf/docker_images/blob/2ad854492209b8dbab303578a5baedab4d5ab41d/ros/iron/ubuntu/jammy/ros-core/Dockerfile)
- [`iron-ros-base`, `iron-ros-base-jammy`, `iron`](https://github.com/osrf/docker_images/blob/bca53bf4c09d771be3ff735da4157203b53ebc2b/ros/iron/ubuntu/jammy/ros-base/Dockerfile)
- [`iron-perception`, `iron-perception-jammy`](https://github.com/osrf/docker_images/blob/bca53bf4c09d771be3ff735da4157203b53ebc2b/ros/iron/ubuntu/jammy/perception/Dockerfile)
- [`jazzy-ros-core`, `jazzy-ros-core-noble`](https://github.com/osrf/docker_images/blob/b525e9ef659ce448db6150fd5407ef62b2c5b265/ros/jazzy/ubuntu/noble/ros-core/Dockerfile)
- [`jazzy-ros-base`, `jazzy-ros-base-noble`, `jazzy`, `latest`](https://github.com/osrf/docker_images/blob/0038f1c3a11aa0fc573d698b39ab5c204aad5a40/ros/jazzy/ubuntu/noble/ros-base/Dockerfile)
- [`jazzy-perception`, `jazzy-perception-noble`](https://github.com/osrf/docker_images/blob/0038f1c3a11aa0fc573d698b39ab5c204aad5a40/ros/jazzy/ubuntu/noble/perception/Dockerfile)
- [`rolling-ros-core`, `rolling-ros-core-noble`](https://github.com/osrf/docker_images/blob/2e9b4e3c02bff2c70271e6f0fd15d4132e8cbcbb/ros/rolling/ubuntu/noble/ros-core/Dockerfile)
- [`rolling-ros-base`, `rolling-ros-base-noble`, `rolling`](https://github.com/osrf/docker_images/blob/2e9b4e3c02bff2c70271e6f0fd15d4132e8cbcbb/ros/rolling/ubuntu/noble/ros-base/Dockerfile)
- [`rolling-perception`, `rolling-perception-noble`](https://github.com/osrf/docker_images/blob/2e9b4e3c02bff2c70271e6f0fd15d4132e8cbcbb/ros/rolling/ubuntu/noble/perception/Dockerfile)
# Quick reference (cont.)
- **Where to file issues**:
[https://github.com/osrf/docker_images/issues](https://github.com/osrf/docker_images/issues?q=)
- **Supported architectures**: ([more info](https://github.com/docker-library/official-images#architectures-other-than-amd64))
[`amd64`](https://hub.docker.com/r/amd64/ros/), [`arm32v7`](https://hub.docker.com/r/arm32v7/ros/), [`arm64v8`](https://hub.docker.com/r/arm64v8/ros/)
- **Published image artifact details**:
[repo-info repo's `repos/ros/` directory](https://github.com/docker-library/repo-info/blob/master/repos/ros) ([history](https://github.com/docker-library/repo-info/commits/master/repos/ros))
(image metadata, transfer size, etc)
- **Image updates**:
[official-images repo's `library/ros` label](https://github.com/docker-library/official-images/issues?q=label%3Alibrary%2Fros)
[official-images repo's `library/ros` file](https://github.com/docker-library/official-images/blob/master/library/ros) ([history](https://github.com/docker-library/official-images/commits/master/library/ros))
- **Source of this description**:
[docs repo's `ros/` directory](https://github.com/docker-library/docs/tree/master/ros) ([history](https://github.com/docker-library/docs/commits/master/ros))
# What is [ROS](https://www.ros.org/)?
The Robot Operating System (ROS) is a set of software libraries and tools that help you build robot applications. From drivers to state-of-the-art algorithms, and with powerful developer tools, ROS has what you need for your next robotics project. And it's all open source.
> [wikipedia.org/wiki/Robot_Operating_System](https://en.wikipedia.org/wiki/Robot_Operating_System)
[](https://www.ros.org/)
# How to use this image
## Creating a `Dockerfile` to install ROS packages
To create your own ROS docker images and install custom packages, here's a simple example of installing the C++, Python client library demos using the official released Debian packages via apt-get.
```dockerfile
FROM ros:foxy
# install ros package
RUN apt-get update && apt-get install -y \
ros-${ROS_DISTRO}-demo-nodes-cpp \
ros-${ROS_DISTRO}-demo-nodes-py && \
rm -rf /var/lib/apt/lists/*
# launch ros package
CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"]
```
Note: all ROS images include a default entrypoint that sources the ROS environment setup before executing the configured command, in this case the demo packages launch file. You can then build and run the Docker image like so:
```console
$ docker build -t my/ros:app .
$ docker run -it --rm my/ros:app
[INFO] [launch]: process[talker-1]: started with pid [813]
[INFO] [launch]: process[listener-2]: started with pid [814]
[INFO] [talker]: Publishing: 'Hello World: 1'
[INFO] [listener]: I heard: [Hello World: 1]
[INFO] [talker]: Publishing: 'Hello World: 2'
[INFO] [listener]: I heard: [Hello World: 2]
...
```
## Creating a `Dockerfile` to build ROS packages
To create your own ROS docker images and build custom packages, here's a simple example of installing a package's build dependencies, compiling it from source, and installing the resulting build artifacts into a final multi-stage image layer.
```dockerfile
ARG FROM_IMAGE=ros:foxy
ARG OVERLAY_WS=/opt/ros/overlay_ws
# multi-stage for caching
FROM $FROM_IMAGE AS cacher
# clone overlay source
ARG OVERLAY_WS
WORKDIR $OVERLAY_WS/src
RUN echo "\
repositories: \n\
ros2/demos: \n\
type: git \n\
url: https://github.com/ros2/demos.git \n\
version: ${ROS_DISTRO} \n\
" > ../overlay.repos
RUN vcs import ./ < ../overlay.repos
# copy manifests for caching
WORKDIR /opt
RUN mkdir -p /tmp/opt && \
find ./ -name "package.xml" | \
xargs cp --parents -t /tmp/opt && \
find ./ -name "COLCON_IGNORE" | \
xargs cp --parents -t /tmp/opt || true
# multi-stage for building
FROM $FROM_IMAGE AS builder
# install overlay dependencies
ARG OVERLAY_WS
WORKDIR $OVERLAY_WS
COPY --from=cacher /tmp/$OVERLAY_WS/src ./src
RUN . /opt/ros/$ROS_DISTRO/setup.sh && \
apt-get update && rosdep install -y \
--from-paths \
src/ros2/demos/demo_nodes_cpp \
src/ros2/demos/demo_nodes_py \
--ignore-src \
&& rm -rf /var/lib/apt/lists/*
# build overlay source
COPY --from=cacher $OVERLAY_WS/src ./src
ARG OVERLAY_MIXINS="release"
RUN . /opt/ros/$ROS_DISTRO/setup.sh && \
colcon build \
--packages-select \
demo_nodes_cpp \
demo_nodes_py \
--mixin $OVERLAY_MIXINS
# source entrypoint setup
ENV OVERLAY_WS $OVERLAY_WS
RUN sed --in-place --expression \
'$isource "$OVERLAY_WS/install/setup.bash"' \
/ros_entrypoint.sh
# run launch file
CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"]
```
The example above starts by using [`vcstool`](https://github.com/dirk-thomas/vcstool) to clone source repos of interest into the cacher stage. One could similarly `COPY` code from the local build context into the source directory as well. Package manifest files are then cached in a temporary directory where the following builder stage may copy from to install necessary dependencies with [`rosdep`](https://github.com/ros-infrastructure/rosdep). This is done prior to copying the rest of the source files to preserve the multi-stage build cache, given unaltered manifests do not alter declared dependencies, saving time and bandwidth. The overlay is then built using [`colcon`](https://colcon.readthedocs.io/en/released/), the entrypoint updated to source the workspace, and the default command set to launch the demo.
Note: `--from-paths` and `--packages-select` are set here as so to only install the dependencies and build for the demo C++ and Python packages, among many in the demo git repo that was cloned. To install the dependencies and build all the packages in the source workspace, merely change the scope by setting `--from-paths src/` and dropping the `--packages-select` arguments.
For more advance examples such as daisy chaining multiple overlay workspaces to improve caching of docker image build layers, using tools such as ccache to accelerate compilation with colcon, or using buildkit to save build time and bandwidth even when dependencies change, the project `Dockerfile`s in the ROS 2 [Navigation2](https://github.com/ros-planning/navigation2) repo are excellent resources.
## Deployment use cases
This dockerized image of ROS is intended to provide a simplified and consistent platform to build and deploy distributed robotic applications. Built from the [official Ubuntu image](https://hub.docker.com/_/ubuntu/) and ROS's official Debian packages, it includes recent supported releases for quick access and download. This provides roboticists in research and industry with an easy way to develop, reuse and ship software for autonomous actions and task planning, control dynamics, localization and mapping, swarm behavior, as well as general system integration.
Developing such complex systems with cutting edge implementations of newly published algorithms remains challenging, as repeatability and reproducibility of robotic software can fall to the wayside in the race to innovate. With the added difficulty in coding, tuning and deploying multiple software components that span across many engineering disciplines, a more collaborative approach becomes attractive. However, the technical difficulties in sharing and maintaining a collection of software over multiple robots and platforms has for a while exceeded time and effort than many smaller labs and businesses could afford.
With the advancements and standardization of software containers, roboticists are primed to acquire a host of improved developer tooling for building and shipping software. To help alleviate the growing pains and technical challenges of adopting new practices, we have focused on providing an official resource for using ROS with these new technologies.
For a complete listing of supported architectures and base images for each ROS Distribution Release, please read the official REP on target platforms for either [ROS 1](https://www.ros.org/reps/rep-0003.html) or for [ROS 2](https://www.ros.org/reps/rep-2000.html).
## Deployment suggestions
The available tags include supported distros along with a hierarchy tags based off the most common meta-package dependencies, designed to have a small footprint and simple configuration:
- `ros-core`: minimal ROS install
- `ros-base`: basic tools and libraries (also tagged with distro name with LTS version as `latest`)
- `ros1-bridge`: tools and libraries to run hybrid ROS 1 - ROS 2 systems and bridge messages between them
In the interest of keeping `ros-core` tag minimal in image size, developer tools such as `rosdep`, `colcon` and `vcstools` are not shipped in `ros_core`, but in `ros-base` instead.
The rest of the common meta-packages such as `desktop` are hosted on repos under OSRF's Docker Hub profile [here](https://hub.docker.com/r/osrf/ros/). These meta-packages include graphical dependencies and hook a host of other large packages such as X11, X server, etc. So in the interest of keeping the official images lean and secure, the desktop packages are just being hosted with OSRF's profile. For an extensive list of available variants, please read the official REP on target platforms for either [ROS 1](https://ros.org/reps/rep-0150.html) or for [ROS 2](https://www.ros.org/reps/rep-2001.html).
### Volumes
ROS uses the `~/.ros/` directory for storing logs, and debugging info. If you wish to persist these files beyond the lifecycle of the containers which produced them, the `~/.ros/` folder can be mounted to an external volume on the host, or a derived image can specify volumes to be managed by the Docker engine. By default, the container runs as the `root` user, so `/root/.ros/` would be the full path to these files.
For example, if one wishes to use their own `.ros` folder that already resides in their local home directory, with a username of `ubuntu`, we can simply launch the container with an additional volume argument:
```console
$ docker run -v "/home/ubuntu/.ros/:/root/.ros/" ros
```
### Devices
Some application may require device access for acquiring images from connected cameras, control input from human interface device, or GPUS for hardware acceleration. This can be done using the [`--device`](https://docs.docker.com/engine/reference/commandline/run/#add-host-device-to-container---device) run argument to mount the device inside the container, providing processes inside hardware access.
### Networks
ROS allows for peer-to-peer networking of processes (potentially distributed across machines) that are loosely coupled using the ROS communication infrastructure. ROS implements several different styles of communication, including synchronous RPC-style communication over services, asynchronous streaming of typed data over topics, combinations of both prior via request/reply and status/feedback over actions, and run-time settings via configuration over parameters. To abide by the best practice of [one process per container](https://docs.docker.com/articles/dockerfile_best-practices/), Docker networks can be used to string together several running ROS processes. For further details see the Deployment example further below.
Alternatively, more permissive network settings can be used to share all host network interfaces with the container, such as [`host` network driver](https://docs.docker.com/network/host/), simplifying connectivity with external network participants. Be aware however that this removes the networking namespace separation between containers, and can affect the ability of DDS participants to communicate between containers, as documented [here](https://community.rti.com/kb/how-use-rti-connext-dds-communicate-across-docker-containers-using-host-driver).
## Deployment example
### Docker Compose
In this example we'll demonstrate using [`docker compose`](https://docs.docker.com/compose/) to spawn a pair of message publisher and subscriber nodes in separate containers connected through shared software defined network.
> Create the directory `~/ros_demos` and add the first `Dockerfile` example from above. In the same directory, also create file `compose.yaml` with the following that runs a C++ publisher with a Python subscriber:
```yaml
services:
talker:
build: ./
command: ros2 run demo_nodes_cpp talker
listener:
build: ./
environment:
- "PYTHONUNBUFFERED=1"
command: ros2 run demo_nodes_py listener
```
> Use `docker compose` inside the same directory to launch our ROS nodes. Given the containers created derive from the same docker compose project, they will coexist on shared project network:
```console
$ docker compose up -d
```
> Notice that a new network named `ros_demos_default` has been created, as can be shown further with:
```console
$ docker network inspect ros_demos_default
```
> We can monitor the logged output of each container, such as the listener node like so:
```console
$ docker compose logs listener
```
> Finally, we can stop and remove all the relevant containers using `docker compose` from the same directory:
```console
$ docker compose stop
$ docker compose rm
```
> Note: the auto-generated network, `ros_demos_default`, will persist until you explicitly remove it using `docker compose down`.
### ROS 1 Bridge
To ease ROS 2 migration, [`ros1_bridge`](https://index.ros.org/p/ros1_bridge) is a ROS 2 package that provides bidirectional communication between ROS 1 and ROS 2. As a minimal example, given the ROS 2 Dockerfile above, we'll create the ROS 1 equivalent below, and name the Dockerfile appropriately.
```dockerfile
FROM ros:noetic
# install ros package
RUN apt-get update && apt-get install -y \
ros-${ROS_DISTRO}-ros-tutorials \
ros-${ROS_DISTRO}-common-tutorials && \
rm -rf /var/lib/apt/lists/*
# launch ros package
CMD ["roslaunch", "roscpp_tutorials", "talker_listener_launch"]
```
The compose file bellow spawns services for both talker listener demos while connecting the two via a dynamic bridge. You may then view the log output from both pairs of talker and listener nodes cross talking over the `/chatter` topic.
```yaml
services:
ros1:
build:
context: ./
dockerfile: ros1.Dockerfile
ros2:
build:
context: ./
dockerfile: ros2.Dockerfile
bridge:
image: ros:foxy-ros1-bridge
environment:
- "ROS_HOSTNAME=bridge"
- "ROS_MASTER_URI=http://ros1:11311"
command: ros2 run ros1_bridge dynamic_bridge
```
# More Resources
[ROS.org](http://www.ros.org/): Main ROS website
[Q&A](https://answers.ros.org/questions/): Ask questions. Get answers
[Forums](https://discourse.ros.org/): Hear the latest discussions
[Blog](http://www.ros.org/news/): Stay up-to-date
[Packages](https://index.ros.org/?search_packages=true): Discover indexed packages
[OSRF](https://www.osrfoundation.org/): Open Source Robotics Foundation
## ROS 2
[Index](https://docs.ros.org): ROS 2 Documentation
[Design](https://design.ros2.org/): ROS 2 Design Articles
## ROS 1
[Wiki](http://wiki.ros.org/Documentation): ROS 1 Documentation
# License
View [package index](https://index.ros.org/packages/) for license information on software contained in this image.
As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).
Some additional license information which was able to be auto-detected might be found in [the `repo-info` repository's `ros/` directory](https://github.com/docker-library/repo-info/tree/master/repos/ros).
As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.
```
--------------------------------------------------------------------------------
/wordpress/README.md:
--------------------------------------------------------------------------------
```markdown
<!--
********************************************************************************
WARNING:
DO NOT EDIT "wordpress/README.md"
IT IS AUTO-GENERATED
(from the other files in "wordpress/" combined with a set of templates)
********************************************************************************
-->
# Quick reference
- **Maintained by**:
[the Docker Community](https://github.com/docker-library/wordpress)
- **Where to get help**:
[the Docker Community Slack](https://dockr.ly/comm-slack), [Server Fault](https://serverfault.com/help/on-topic), [Unix & Linux](https://unix.stackexchange.com/help/on-topic), or [Stack Overflow](https://stackoverflow.com/help/on-topic)
# Supported tags and respective `Dockerfile` links
- [`6.8.1-php8.1-apache`, `6.8-php8.1-apache`, `6-php8.1-apache`, `php8.1-apache`, `6.8.1-php8.1`, `6.8-php8.1`, `6-php8.1`, `php8.1`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.1/apache/Dockerfile)
- [`6.8.1-php8.1-fpm`, `6.8-php8.1-fpm`, `6-php8.1-fpm`, `php8.1-fpm`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.1/fpm/Dockerfile)
- [`6.8.1-php8.1-fpm-alpine`, `6.8-php8.1-fpm-alpine`, `6-php8.1-fpm-alpine`, `php8.1-fpm-alpine`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.1/fpm-alpine/Dockerfile)
- [`6.8.1-apache`, `6.8-apache`, `6-apache`, `apache`, `6.8.1`, `6.8`, `6`, `latest`, `6.8.1-php8.2-apache`, `6.8-php8.2-apache`, `6-php8.2-apache`, `php8.2-apache`, `6.8.1-php8.2`, `6.8-php8.2`, `6-php8.2`, `php8.2`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.2/apache/Dockerfile)
- [`6.8.1-fpm`, `6.8-fpm`, `6-fpm`, `fpm`, `6.8.1-php8.2-fpm`, `6.8-php8.2-fpm`, `6-php8.2-fpm`, `php8.2-fpm`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.2/fpm/Dockerfile)
- [`6.8.1-fpm-alpine`, `6.8-fpm-alpine`, `6-fpm-alpine`, `fpm-alpine`, `6.8.1-php8.2-fpm-alpine`, `6.8-php8.2-fpm-alpine`, `6-php8.2-fpm-alpine`, `php8.2-fpm-alpine`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.2/fpm-alpine/Dockerfile)
- [`6.8.1-php8.3-apache`, `6.8-php8.3-apache`, `6-php8.3-apache`, `php8.3-apache`, `6.8.1-php8.3`, `6.8-php8.3`, `6-php8.3`, `php8.3`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.3/apache/Dockerfile)
- [`6.8.1-php8.3-fpm`, `6.8-php8.3-fpm`, `6-php8.3-fpm`, `php8.3-fpm`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.3/fpm/Dockerfile)
- [`6.8.1-php8.3-fpm-alpine`, `6.8-php8.3-fpm-alpine`, `6-php8.3-fpm-alpine`, `php8.3-fpm-alpine`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.3/fpm-alpine/Dockerfile)
- [`6.8.1-php8.4-apache`, `6.8-php8.4-apache`, `6-php8.4-apache`, `php8.4-apache`, `6.8.1-php8.4`, `6.8-php8.4`, `6-php8.4`, `php8.4`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.4/apache/Dockerfile)
- [`6.8.1-php8.4-fpm`, `6.8-php8.4-fpm`, `6-php8.4-fpm`, `php8.4-fpm`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.4/fpm/Dockerfile)
- [`6.8.1-php8.4-fpm-alpine`, `6.8-php8.4-fpm-alpine`, `6-php8.4-fpm-alpine`, `php8.4-fpm-alpine`](https://github.com/docker-library/wordpress/blob/b8721d7271bf763d999285985277d61e78c584aa/latest/php8.4/fpm-alpine/Dockerfile)
- [`cli-2.12.0-php8.1`, `cli-2.12-php8.1`, `cli-2-php8.1`, `cli-php8.1`](https://github.com/docker-library/wordpress/blob/50da133eabc137fa07c620c77788c1237cf55c8b/cli/php8.1/alpine/Dockerfile)
- [`cli-2.12.0`, `cli-2.12`, `cli-2`, `cli`, `cli-2.12.0-php8.2`, `cli-2.12-php8.2`, `cli-2-php8.2`, `cli-php8.2`](https://github.com/docker-library/wordpress/blob/50da133eabc137fa07c620c77788c1237cf55c8b/cli/php8.2/alpine/Dockerfile)
- [`cli-2.12.0-php8.3`, `cli-2.12-php8.3`, `cli-2-php8.3`, `cli-php8.3`](https://github.com/docker-library/wordpress/blob/50da133eabc137fa07c620c77788c1237cf55c8b/cli/php8.3/alpine/Dockerfile)
- [`cli-2.12.0-php8.4`, `cli-2.12-php8.4`, `cli-2-php8.4`, `cli-php8.4`](https://github.com/docker-library/wordpress/blob/50da133eabc137fa07c620c77788c1237cf55c8b/cli/php8.4/alpine/Dockerfile)
# Quick reference (cont.)
- **Where to file issues**:
[https://github.com/docker-library/wordpress/issues](https://github.com/docker-library/wordpress/issues?q=)
- **Supported architectures**: ([more info](https://github.com/docker-library/official-images#architectures-other-than-amd64))
[`amd64`](https://hub.docker.com/r/amd64/wordpress/), [`arm32v5`](https://hub.docker.com/r/arm32v5/wordpress/), [`arm32v6`](https://hub.docker.com/r/arm32v6/wordpress/), [`arm32v7`](https://hub.docker.com/r/arm32v7/wordpress/), [`arm64v8`](https://hub.docker.com/r/arm64v8/wordpress/), [`i386`](https://hub.docker.com/r/i386/wordpress/), [`mips64le`](https://hub.docker.com/r/mips64le/wordpress/), [`ppc64le`](https://hub.docker.com/r/ppc64le/wordpress/), [`riscv64`](https://hub.docker.com/r/riscv64/wordpress/), [`s390x`](https://hub.docker.com/r/s390x/wordpress/)
- **Published image artifact details**:
[repo-info repo's `repos/wordpress/` directory](https://github.com/docker-library/repo-info/blob/master/repos/wordpress) ([history](https://github.com/docker-library/repo-info/commits/master/repos/wordpress))
(image metadata, transfer size, etc)
- **Image updates**:
[official-images repo's `library/wordpress` label](https://github.com/docker-library/official-images/issues?q=label%3Alibrary%2Fwordpress)
[official-images repo's `library/wordpress` file](https://github.com/docker-library/official-images/blob/master/library/wordpress) ([history](https://github.com/docker-library/official-images/commits/master/library/wordpress))
- **Source of this description**:
[docs repo's `wordpress/` directory](https://github.com/docker-library/docs/tree/master/wordpress) ([history](https://github.com/docker-library/docs/commits/master/wordpress))
# What is WordPress?
WordPress is a free and open source blogging tool and a content management system (CMS) based on PHP and MySQL, which runs on a web hosting service. Features include a plugin architecture and a template system. WordPress is used by more than 22.0% of the top 10 million websites as of August 2013. WordPress is the most popular blogging system in use on the Web, at more than 60 million websites. The most popular languages used are English, Spanish and Bahasa Indonesia.
> [wikipedia.org/wiki/WordPress](https://en.wikipedia.org/wiki/WordPress)
# How to use this image
```console
$ docker run --name some-wordpress --network some-network -d wordpress
```
The following environment variables are also honored for configuring your WordPress instance (by [a custom `wp-config.php` implementation](https://github.com/docker-library/wordpress/blob/master/wp-config-docker.php)):
- `-e WORDPRESS_DB_HOST=...`
- `-e WORDPRESS_DB_USER=...`
- `-e WORDPRESS_DB_PASSWORD=...`
- `-e WORDPRESS_DB_NAME=...`
- `-e WORDPRESS_TABLE_PREFIX=...`
- `-e WORDPRESS_AUTH_KEY=...`, `-e WORDPRESS_SECURE_AUTH_KEY=...`, `-e WORDPRESS_LOGGED_IN_KEY=...`, `-e WORDPRESS_NONCE_KEY=...`, `-e WORDPRESS_AUTH_SALT=...`, `-e WORDPRESS_SECURE_AUTH_SALT=...`, `-e WORDPRESS_LOGGED_IN_SALT=...`, `-e WORDPRESS_NONCE_SALT=...` (default to unique random SHA1s, but only if other environment variable configuration is provided)
- `-e WORDPRESS_DEBUG=1` (defaults to disabled, non-empty value will enable `WP_DEBUG` in `wp-config.php`)
- `-e WORDPRESS_CONFIG_EXTRA=...` (defaults to nothing, the value will be evaluated by the `eval()` function in `wp-config.php`. This variable is especially useful for applying extra configuration values this image does not provide by default such as `WP_ALLOW_MULTISITE`; see [docker-library/wordpress#142](https://github.com/docker-library/wordpress/pull/142) for more details)
The `WORDPRESS_DB_NAME` needs to already exist on the given MySQL server; it will not be created by the `wordpress` container.
If you'd like to be able to access the instance from the host without the container's IP, standard port mappings can be used:
```console
$ docker run --name some-wordpress -p 8080:80 -d wordpress
```
Then, access it via `http://localhost:8080` or `http://host-ip:8080` in a browser.
When running WordPress with TLS behind a reverse proxy such as NGINX which is responsible for doing TLS termination, be sure to set `X-Forwarded-Proto` appropriately (see ["Using a Reverse Proxy" in "Administration Over SSL" in upstream's documentation](https://wordpress.org/support/article/administration-over-ssl/#using-a-reverse-proxy)). No additional environment variables or configuration should be necessary (this image automatically adds the noted `HTTP_X_FORWARDED_PROTO` code to `wp-config.php` if *any* of the above-noted environment variables are specified).
If your database requires SSL, [WordPress ticket #28625](https://core.trac.wordpress.org/ticket/28625) has the relevant details regarding support for that with WordPress upstream. As a workaround, [the "Secure DB Connection" plugin](https://wordpress.org/plugins/secure-db-connection/) can be extracted into the WordPress directory and the appropriate values described in the configuration of that plugin added in `wp-config.php`.
## Docker Secrets
As an alternative to passing sensitive information via environment variables, `_FILE` may be appended to the previously listed environment variables, causing the initialization script to load the values for those variables from files present in the container. In particular, this can be used to load passwords from Docker secrets stored in `/run/secrets/<secret_name>` files. For example:
```console
$ docker run --name some-wordpress -e WORDPRESS_DB_PASSWORD_FILE=/run/secrets/mysql-root ... -d wordpress:tag
```
Currently, this is supported for `WORDPRESS_DB_HOST`, `WORDPRESS_DB_USER`, `WORDPRESS_DB_PASSWORD`, `WORDPRESS_DB_NAME`, `WORDPRESS_AUTH_KEY`, `WORDPRESS_SECURE_AUTH_KEY`, `WORDPRESS_LOGGED_IN_KEY`, `WORDPRESS_NONCE_KEY`, `WORDPRESS_AUTH_SALT`, `WORDPRESS_SECURE_AUTH_SALT`, `WORDPRESS_LOGGED_IN_SALT`, `WORDPRESS_NONCE_SALT`, `WORDPRESS_TABLE_PREFIX`, and `WORDPRESS_DEBUG`.
## ... via [`docker compose`](https://github.com/docker/compose)
Example `compose.yaml` for `wordpress`:
```yaml
services:
wordpress:
image: wordpress
restart: always
ports:
- 8080:80
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: exampleuser
WORDPRESS_DB_PASSWORD: examplepass
WORDPRESS_DB_NAME: exampledb
volumes:
- wordpress:/var/www/html
db:
image: mysql:8.0
restart: always
environment:
MYSQL_DATABASE: exampledb
MYSQL_USER: exampleuser
MYSQL_PASSWORD: examplepass
MYSQL_RANDOM_ROOT_PASSWORD: '1'
volumes:
- db:/var/lib/mysql
volumes:
wordpress:
db:
```
Run `docker compose up`, wait for it to initialize completely, and visit `http://localhost:8080` or `http://host-ip:8080` (as appropriate).
## Adding additional libraries / extensions
This image does not provide any additional PHP extensions or other libraries, even if they are required by popular plugins (e.g. [it cannot send e-mails](https://github.com/docker-library/wordpress/issues/30)). There are an infinite number of possible plugins, and they potentially require any extension PHP supports. Including every PHP extension that exists would dramatically increase the image size.
If you need additional PHP extensions, you'll need to create your own image `FROM` this one. The [documentation of the `php` image](https://github.com/docker-library/docs/blob/master/php/README.md#how-to-install-more-php-extensions) explains how to compile additional extensions. Additionally, [an older `Dockerfile` for `wordpress`](https://github.com/docker-library/wordpress/blob/618490d4bdff6c5774b84b717979bfe3d6ba8ad1/apache/Dockerfile#L5-L9) has a simplified example of doing this and [a newer version of that same `Dockerfile`](https://github.com/docker-library/wordpress/blob/5bbbfa8909232af10ea3fea8b80302a6041a2d04/latest/php7.4/apache/Dockerfile#L18-L62) has a much more thorough example.
## Include pre-installed themes / plugins
Mount the volume containing your themes or plugins to the proper directory; and then apply them through the "wp-admin" UI. Ensure read/write/execute permissions are in place for the user:
- Themes go in a subdirectory in `/var/www/html/wp-content/themes/`
- Plugins go in a subdirectory in `/var/www/html/wp-content/plugins/`
If you wish to provide additional content in an image for deploying in multiple installations, place it in the same directories under `/usr/src/wordpress/` instead (which gets copied to `/var/www/html/` on the container's initial startup).
## Static image / updates-via-redeploy
The default configuration for this image matches the official WordPress defaults in which automatic updates are enabled (so the initial install comes from the image, but after that it becomes self-managing within the `/var/www/html/` data volume).
If you wish to have a more static deployment (similar to other containerized applications) and deploy new containers to update WordPress + themes/plugins, then you'll want to use something like the following (and run the resulting image read-only):
```dockerfile
FROM wordpress:apache
WORKDIR /usr/src/wordpress
RUN set -eux; \
find /etc/apache2 -name '*.conf' -type f -exec sed -ri -e "s!/var/www/html!$PWD!g" -e "s!Directory /var/www/!Directory $PWD!g" '{}' +; \
cp -s wp-config-docker.php wp-config.php
COPY custom-theme/ ./wp-content/themes/custom-theme/
COPY custom-plugin/ ./wp-content/plugins/custom-plugin/
```
For FPM-based images, remove the `find` instruction and adjust the `SCRIPT_FILENAME` paths in your reverse proxy from `/var/www/html` to `/usr/src/wordpress`.
Run the result read-only, providing writeable storage for `/tmp`, `/run`, and (optionally) `wp-content/uploads`:
```console
$ docker run ... \
--read-only \
--tmpfs /tmp \
--tmpfs /run \
--mount type=...,src=...,dst=/usr/src/wordpress/wp-content/uploads \
... \
--env WORDPRESS_DB_HOST=... \
--env WORDPRESS_AUTH_KEY=... \
--env ... \
custom-wordpress:tag
```
**Note:** be sure to rebuild and redeploy regularly to ensure you get all the latest WordPress security updates.
## Running as an arbitrary user
See [the "Running as an arbitrary user" section of the `php` image documentation](https://github.com/docker-library/docs/blob/master/php/README.md#running-as-an-arbitrary-user).
When running WP-CLI via the `cli` variants of this image, it is important to note that they're based on Alpine, and have a default `USER` of Alpine's `www-data`, whose UID is `82` (compared to the Debian-based WordPress variants whose default effective UID is `33`), so when running `wordpress:cli` against an existing Debian-based WordPress install, something like `--user 33:33` is likely going to be necessary (possibly also something like `-e HOME=/tmp` depending on the `wp` command invoked and whether it tries to use `~/.wp-cli`). See [docker-library/wordpress#256](https://github.com/docker-library/wordpress/issues/256) for more discussion around this.
## Configuring PHP directives
See [the "Configuration" section of the `php` image documentation](https://github.com/docker-library/docs/blob/master/php/README.md#configuration).
For example, to adjust common `php.ini` flags like `upload_max_filesize`, you could create a `custom.ini` with the desired parameters and place it in the `$PHP_INI_DIR/conf.d/` directory:
```dockerfile
FROM wordpress:tag
COPY custom.ini $PHP_INI_DIR/conf.d/
```
# Image Variants
The `wordpress` images come in many flavors, each designed for a specific use case.
## `wordpress:<version>`
This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
## `wordpress:<version>-fpm`
This variant contains [PHP's FastCGI Process Manager (FPM)](https://www.php.net/fpm), which is the recommended FastCGI implementation for PHP.
In order to use this image variant, some kind of reverse proxy (such as NGINX, Apache, or other tool which speaks the FastCGI protocol) will be required.
Some potentially helpful resources:
- [FPM's Official Configuration Reference](https://www.php.net/manual/en/install.fpm.configuration.php)
- [Simplified example by @md5](https://gist.github.com/md5/d9206eacb5a0ff5d6be0)
- [Very detailed article by Pascal Landau](https://www.pascallandau.com/blog/php-php-fpm-and-nginx-on-docker-in-windows-10/)
- [Stack Overflow discussion](https://stackoverflow.com/q/29905953/433558)
- [Apache httpd Wiki example](https://wiki.apache.org/httpd/PHPFPMWordpress)
**WARNING:** the FastCGI protocol is inherently trusting, and thus *extremely* insecure to expose outside of a private container network -- unless you know *exactly* what you are doing (and are willing to accept the extreme risk), do not use Docker's `--publish` (`-p`) flag with this image variant.
## `wordpress:cli`
This image variant does not contain WordPress itself, but instead contains [WP-CLI](https://wp-cli.org).
The simplest way to use it with an existing WordPress container would be something similar to the following:
```console
$ docker run -it --rm \
--volumes-from some-wordpress \
--network container:some-wordpress \
-e WORDPRESS_DB_USER=... \
-e WORDPRESS_DB_PASSWORD=... \
# [and other used environment variables]
wordpress:cli user list
```
Generally speaking, for WP-CLI to interact with a WordPress install, it needs access to the on-disk files of the WordPress install, and access to the database (and the easiest way to accomplish that such that `wp-config.php` does not require changes is to simply join the networking context of the existing and presumably working WordPress container, but there are many other ways to accomplish that which will be left as an exercise for the reader).
**NOTE:** Since March 2021, WordPress images use a customized `wp-config.php` that pulls the values directly from the environment variables defined above (see `wp-config-docker.php` in [docker-library/wordpress#572](https://github.com/docker-library/wordpress/pull/572) and [docker-library/wordpress#577](https://github.com/docker-library/wordpress/pull/577)). As a result of reading environment variables directly, the cli container also needs the same set of environment variables to properly evaluate `wp-config.php`.
# License
View [license information](https://wordpress.org/about/license/) for the software contained in this image.
As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).
Some additional license information which was able to be auto-detected might be found in [the `repo-info` repository's `wordpress/` directory](https://github.com/docker-library/repo-info/tree/master/repos/wordpress).
As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.
```
--------------------------------------------------------------------------------
/mariadb/README.md:
--------------------------------------------------------------------------------
```markdown
<!--
********************************************************************************
WARNING:
DO NOT EDIT "mariadb/README.md"
IT IS AUTO-GENERATED
(from the other files in "mariadb/" combined with a set of templates)
********************************************************************************
-->
# Quick reference
- **Maintained by**:
[MariaDB Foundation](https://mariadb.org), [MariaDB plc](https://mariadb.com), with contributions from our [community](https://github.com/MariaDB/mariadb-docker)
- **Where to get help**:
[Database Adminstrators (Stack Exchange)](https://dba.stackexchange.com/questions/tagged/docker+mariadb), [MariaDB Knowledge Base](https://mariadb.com/kb/en/docker-and-mariadb/) ([Ask a Question here](https://mariadb.com/kb/en/docker-and-mariadb/ask)).
Also see the ["Getting Help with MariaDB" article on the MariaDB Knowledge Base](https://mariadb.com/kb/en/getting-help-with-mariadb/).
# Supported tags and respective `Dockerfile` links
- [`11.8.1-ubi9-rc`, `11.8-ubi9-rc`, `11.8.1-ubi-rc`, `11.8-ubi-rc`](https://github.com/MariaDB/mariadb-docker/blob/2d5103917774c4c53ec6bf3c6fdfc7b210e85690/11.8-ubi/Dockerfile)
- [`11.8.1-noble-rc`, `11.8-noble-rc`, `11.8.1-rc`, `11.8-rc`](https://github.com/MariaDB/mariadb-docker/blob/2d5103917774c4c53ec6bf3c6fdfc7b210e85690/11.8/Dockerfile)
- [`11.7.2-ubi9`, `11.7-ubi9`, `11-ubi9`, `11.7.2-ubi`, `11.7-ubi`, `11-ubi`](https://github.com/MariaDB/mariadb-docker/blob/853447019725b35685d5ec3c007096a266399bea/11.7-ubi/Dockerfile)
- [`11.7.2-noble`, `11.7-noble`, `11-noble`, `noble`, `11.7.2`, `11.7`, `11`, `latest`](https://github.com/MariaDB/mariadb-docker/blob/853447019725b35685d5ec3c007096a266399bea/11.7/Dockerfile)
- [`11.4.5-ubi9`, `11.4-ubi9`, `lts-ubi9`, `11.4.5-ubi`, `11.4-ubi`, `lts-ubi`](https://github.com/MariaDB/mariadb-docker/blob/3bfeae408bde492aad0444cbb13d55a70ceec6e5/11.4-ubi/Dockerfile)
- [`11.4.5-noble`, `11.4-noble`, `lts-noble`, `11.4.5`, `11.4`, `lts`](https://github.com/MariaDB/mariadb-docker/blob/3bfeae408bde492aad0444cbb13d55a70ceec6e5/11.4/Dockerfile)
- [`10.11.11-ubi9`, `10.11-ubi9`, `10-ubi9`, `10.11.11-ubi`, `10.11-ubi`, `10-ubi`](https://github.com/MariaDB/mariadb-docker/blob/3bfeae408bde492aad0444cbb13d55a70ceec6e5/10.11-ubi/Dockerfile)
- [`10.11.11-jammy`, `10.11-jammy`, `10-jammy`, `10.11.11`, `10.11`, `10`](https://github.com/MariaDB/mariadb-docker/blob/3bfeae408bde492aad0444cbb13d55a70ceec6e5/10.11/Dockerfile)
- [`10.6.21-ubi9`, `10.6-ubi9`, `10.6.21-ubi`, `10.6-ubi`](https://github.com/MariaDB/mariadb-docker/blob/3bfeae408bde492aad0444cbb13d55a70ceec6e5/10.6-ubi/Dockerfile)
- [`10.6.21-focal`, `10.6-focal`, `10.6.21`, `10.6`](https://github.com/MariaDB/mariadb-docker/blob/3bfeae408bde492aad0444cbb13d55a70ceec6e5/10.6/Dockerfile)
- [`10.5.28-focal`, `10.5-focal`, `10.5.28`, `10.5`](https://github.com/MariaDB/mariadb-docker/blob/3bfeae408bde492aad0444cbb13d55a70ceec6e5/10.5/Dockerfile)
# Quick reference (cont.)
- **Where to file issues**:
Issues can be filed on [https://jira.mariadb.org/](https://jira.mariadb.org/) under the "MDEV" Project and "Docker" Component, or on [GitHub](https://github.com/MariaDB/mariadb-docker/issues)
- **Supported architectures**: ([more info](https://github.com/docker-library/official-images#architectures-other-than-amd64))
[`amd64`](https://hub.docker.com/r/amd64/mariadb/), [`arm64v8`](https://hub.docker.com/r/arm64v8/mariadb/), [`ppc64le`](https://hub.docker.com/r/ppc64le/mariadb/), [`s390x`](https://hub.docker.com/r/s390x/mariadb/)
- **Published image artifact details**:
[repo-info repo's `repos/mariadb/` directory](https://github.com/docker-library/repo-info/blob/master/repos/mariadb) ([history](https://github.com/docker-library/repo-info/commits/master/repos/mariadb))
(image metadata, transfer size, etc)
- **Image updates**:
[official-images repo's `library/mariadb` label](https://github.com/docker-library/official-images/issues?q=label%3Alibrary%2Fmariadb)
[official-images repo's `library/mariadb` file](https://github.com/docker-library/official-images/blob/master/library/mariadb) ([history](https://github.com/docker-library/official-images/commits/master/library/mariadb))
- **Source of this description**:
[docs repo's `mariadb/` directory](https://github.com/docker-library/docs/tree/master/mariadb) ([history](https://github.com/docker-library/docs/commits/master/mariadb))
# What is MariaDB?
MariaDB Server is one of the most popular database servers in the world. It's made by the original developers of MySQL and guaranteed to stay open source. Notable users include Wikipedia, DBS Bank, and ServiceNow.
The intent is also to maintain high compatibility with MySQL, ensuring a library binary equivalency and exact matching with MySQL APIs and commands. MariaDB developers continue to develop new features and improve performance to better serve its users.
# How to use this image
The mariadb has a number of tags, and of note is `latest`, as the latest stable version, and `lts`, as the last long term support release.
## Running the container
### Configuration
#### Port binding
By default, the database running within the container will listen on port 3306. You can expose the container port 3306 to the host port 3306 with the `-p 3306:3306` argument to `docker run`, like the command below:
```console
$ docker run --name some-mariadb -p 3306:3306 mariadb:latest
```
### Starting using a minimal configuration
The environment variables required to use this image involves the setting of the root user password:
```console
$ docker run --detach --name some-mariadb --env MARIADB_ROOT_PASSWORD=my-secret-pw mariadb:latest
```
or:
```console
$ docker run --detach --name some-mariadb --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 mariadb:latest
```
or:
```console
$ docker run --detach --name some-mariadb --env MARIADB_RANDOM_ROOT_PASSWORD=1 mariadb:latest
```
... where the container logs will contain the generated root password.
## ... via [`docker compose`](https://github.com/docker/compose)
Example `compose.yaml` for `mariadb`:
```yaml
# Use root/example as user/password credentials
services:
db:
image: mariadb
restart: always
environment:
MARIADB_ROOT_PASSWORD: example
adminer:
image: adminer
restart: always
ports:
- 8080:8080
```
Run `docker compose up`, wait for it to initialize completely, and visit `http://localhost:8080` or `http://host-ip:8080` (as appropriate).
### Start a `mariadb` server instance with user, password and database
Starting a MariaDB instance with a user, password, and a database:
```console
$ docker run --detach --name some-mariadb --env MARIADB_USER=example-user --env MARIADB_PASSWORD=my_cool_secret --env MARIADB_DATABASE=exmple-database --env MARIADB_ROOT_PASSWORD=my-secret-pw mariadb:latest
```
### Start a `mariadb` server instance in a network
As applications talk to MariaDB, MariaDB needs to start in the same network as the application:
```console
$ docker network create some-network
$ docker run --detach --network some-network --name some-mariadb --env MARIADB_USER=example-user --env MARIADB_PASSWORD=my_cool_secret --env MARIADB_ROOT_PASSWORD=my-secret-pw mariadb:latest
$ docker run --detach --network some-network --name some-application --env APP_DB_HOST=some-mariadb --env APP_DB_USER=example-user --env APP_DB_PASSWD=my_cool_secret some-application
```
... where `some-network` is a newly created network (other than `bridge` as the default network), `some-mariadb` is the name you want to assign to your container, `my-secret-pw` is the password to be set for the MariaDB root user. See the list above for relevant tags to match your needs and environment. `some-application` and then environment variable `APP_DB_HOST`, `APP_DB_USER` and `APP_DB_PASSWD` are the application's configuration for its database connection.
## Connect to MariaDB from the MariaDB command line client
The following command starts another `mariadb` container instance and runs the `mariadb` command line client against your original `mariadb` container, allowing you to execute SQL statements against your database instance:
```console
$ docker run -it --network some-network --rm mariadb mariadb -h some-mariadb -u example-user
```
... where `some-mariadb` is the name of your original `mariadb` container (connected to the `some-network` Docker network).
This image can also be used as a client for non-Docker or remote instances:
```console
$ docker run -it --rm mariadb mariadb --host <server container IP> --user example-user --password --database test
```
That will give you a standard MariaDB prompt. You can test it with:
```console
MariaDB [(none)]> \s
--------------
client/mariadb Ver 15.1 Distrib 10.6.16-MariaDB, for Linux (x86_64) using EditLine wrapper
Connection id: 20
Current database: test
Current user: example-user@bark
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server: MariaDB
Server version: 10.6.16-MariaDB Source distribution
Protocol version: 10
Connection: 192.168.178.73 via TCP/IP
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8mb3
Conn. characterset: utf8mb3
TCP port: 3306
Uptime: 6 min 4 sec
Threads: 1 Questions: 32 Slow queries: 0 Opens: 20 Open tables: 13 Queries per second avg: 0.087
--------------
```
... which will give you the version and connection information. You can then use `exit` to leave the MariaDB command line client and the client container.
More information about the MariaDB command-line client can be found in the [MariaDB Knowledge Base : MariaDB Command Line Client](https://mariadb.com/kb/en/mariadb-command-line-client/).
## Container shell access
The `docker exec` command allows you to run commands inside the running container. The following command line will give you a bash shell inside your `mariadb` container:
```console
$ docker exec -it some-mariadb bash
```
## MariaDB-Backup
As MariaDB-Backup is highly coupled with the server version, it can be useful to use the `mariadb-backup` in the mariadb container of an explicit version:
```console
$ docker run --volume /backup-volume:/backup --rm mariadb:10.6.15 mariadb-backup --help
```
## Container viewing MariaDB logs
The log is available through Docker's container log:
```console
$ docker logs some-mariadb
```
## Using a custom MariaDB configuration file
Custom configuration files should end in `.cnf` and be mounted read only at the directory `/etc/mysql/conf.d`. These files should contain the minimal changes from the MariaDB workload required for your application/environment. A MariaDB configuration file will have a `[mariadb]` group followed by `variable` = `value` settings per [Setting Server System Variables](https://mariadb.com/kb/en/server-system-variables/#setting-server-system-variables) or [option-prefix-variable](https://mariadb.com/kb/en/configuring-mariadb-with-option-files/#option-prefixes).
The `mariadb` image configuration contains the Ubuntu MariaDB variables with two custom changes for the container:
[host-cache-size=0](https://mariadb.com/kb/en/server-system-variables/#host_cache_size)
[skip-name-resolve](https://mariadb.com/kb/en/server-system-variables/#skip_name_resolve)
These disable the authentication of `user@hostname` users. To re-enable the `skip-name-resolve` use `disable-skip-name-resolve` as variable or argument. When enabled, the `host-cache-size` should be sufficient for the number of containers connecting to the `mariadb`.
To view the resulting configuration of your `mariadb` container:
```console
$ docker run --name some-mariadb -v /my/custom:/etc/mysql/conf.d --rm mariadb:latest my_print_defaults --mysqld
```
### Configuration without a `cnf` file
Many configuration options can be passed as flags to `mariadbd`. This will give you the flexibility to customize the container without needing a `cnf` file. For example, if you want to run on port 3808 just run the following:
```console
$ docker run --name some-mariadb -e MARIADB_ROOT_PASSWORD=my-secret-pw -d mariadb:latest --port 3808
```
If you would like to see a complete list of available options, just run:
```console
$ docker run -it --rm mariadb:latest --verbose --help
```
## Environment Variables
When you start the `mariadb` image, you can adjust the initialization of the MariaDB instance by passing one or more environment variables on the `docker run` command line. Do note that all of the variables, except `MARIADB_AUTO_UPGRADE`, will have no effect if you start the container with a data directory that already contains a database. I.e. any pre-existing database will always be left untouched on container startup.
One of `MARIADB_RANDOM_ROOT_PASSWORD`, `MARIADB_ROOT_PASSWORD_HASH`, `MARIADB_ROOT_PASSWORD` or `MARIADB_ALLOW_EMPTY_ROOT_PASSWORD` (or equivalents, including `*_FILE`), is required. The other environment variables are optional.
There is a large list of environment variables and the complete list is documented on [MariaDB's Knowledge Base : MariaDB Server Docker Official Image Environment Variables](https://mariadb.com/kb/en/mariadb-server-docker-official-image-environment-variables/).
### `MARIADB_AUTO_UPGRADE`
When this environment variable is set, this will run the [mariadb-upgrade](https://mariadb.com/kb/en/mariadb-upgrade/), if needed, so any changes in the MariaDB system tables required to expose new features will be made. This may impeed some [downgrade options](https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/). Unless the environment variable `MARIADB_DISABLE_UPGRADE_BACKUP` is set, there will be a backup of the system tables created as `system_mysql_backup_*.sql.zst` in the top level of the data directory to assist in the downgrade if needed.
## Secrets
As an alternative to passing sensitive information via environment variables, `_FILE` may be appended to the previously listed environment variables, causing the initialization script to load the values for those variables from files present in the container. In particular, this can be used to load passwords from Docker secrets stored in `/run/secrets/<secret_name>` files. For example:
```console
$ docker run --name some-mysql -e MARIADB_ROOT_PASSWORD_FILE=/run/secrets/mariadb-root -d mariadb:latest
```
# Initializing the database contents
When a container is started for the first time, a new database with the specified name will be created and initialized with the provided configuration variables. Furthermore, it will execute files with extensions `.sh`, `.sql`, `.sql.gz`, `.sql.xz` and `.sql.zst` that are found in `/docker-entrypoint-initdb.d`. Files will be executed in alphabetical order. `.sh` files without file execute permission are sourced rather than executed. You can easily populate your `mariadb` services by [mounting a SQL dump into that directory](https://docs.docker.com/storage/bind-mounts/) and provide [custom images](https://docs.docker.com/reference/dockerfile/) with contributed data. SQL files will be imported by default to the database specified by the `MARIADB_DATABASE` variable.
# Caveats
## Where to Store Data
Important note: There are several ways to store data used by applications that run in Docker containers. We encourage users of the `mariadb` images to familiarize themselves with the options available, including:
- Use a named volume using the container manager to manage the storage of your database data [by writing the database files to disk on the host system using its own internal volume management](https://docs.docker.com/storage/volumes/). This is the default and is easy and fairly transparent to the user. The downside is that the files may be hard to locate for tools and applications that run directly on the host system, i.e. outside containers.
- Create a data directory on the host system (outside the container) and [mount this to a directory visible from inside the container](https://docs.docker.com/storage/bind-mounts/). This places the database files in a known location on the host system, and makes it easy for tools and applications on the host system to access the files. The downside is that the user needs to make sure that the directory exists, and that e.g. directory permissions and other security mechanisms on the host system are set up correctly.
The Docker documentation is a good starting point for understanding the different storage options and variations, and there are multiple blogs and forum postings that discuss and give advice in this area. We will simply show the basic procedure here for the latter option above:
1. Create a data directory on a suitable volume on your host system, e.g. `/my/own/datadir`.
2. Start your `mariadb` container like this:
```console
$ docker run --name some-mariadb -v /my/own/datadir:/var/lib/mysql:Z -e MARIADB_ROOT_PASSWORD=my-secret-pw -d mariadb:latest
```
The `-v /my/own/datadir:/var/lib/mysql:Z` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/var/lib/mysql` inside the container, where MariaDB by default will write its data files.
## No connections until MariaDB init completes
If there is no database initialized when the container starts, then a default database will be created. While this is the expected behavior, this means that it will not accept incoming connections until such initialization completes. This may cause issues when using automation tools, such as `docker compose`, which start several containers simultaneously.
## Health/Liveness/Readiness Checking
See [the "Official Images" FAQ](https://github.com/docker-library/faq#healthcheck) for why there is no default `HEALTHCHECK` directive. However, you can use the `healthcheck.sh` script to choose from a (non-exhaustive) list of tests to check for whatever you consider health/liveness/readiness. Refer to the [MariaDB Knowledge Base : Using Healthcheck.sh](https://mariadb.com/kb/en/using-healthcheck-sh-script/) to learn about how to use it and which exact tests are provided.
## Usage against an existing database
If you start your `mariadb` container instance with a data directory that already contains a database (specifically, a `mysql` subdirectory), no environment variables that control initialization will be needed or examined, and no pre-existing databases will be changed. The only exception is the non-default `MARIADB_AUTO_UPGRADE` environment variable, that might cause `mysql_upgrade`/`mariadb-upgrade` to run, which might change the system tables.
## Backups and Restores
Backing up and restoring databases is important in containers too. The documentation on how to do this can be found on the [MariaDB Knowledge Base : Container Backup and Restoration](https://mariadb.com/kb/en/backups-and-restoration/).
## Frequently Asked Questions / How to reset root and user passwords
This is documented on [MariaDB Knowledge Base : Frequenty Asked Questions of Docker Official Image](https://mariadb.com/kb/en/frequenty-asked-questions-of-docker-official-image/#how-to-reset-passwords).
## How to install MariaDB plugins
This is documented on [MariaDB Knowledge Base : Adding Plugins to the Docker Official Image](https://mariadb.com/kb/en/adding-plugins-to-the-mariadb-docker-official-image/).
# Related Images
- [MariaDB MaxScale](https://hub.docker.com/r/mariadb/maxscale/tags)
- [MariaDB ColumnStore](https://hub.docker.com/r/mariadb/columnstore/tags)
# Compose File Examples
Example compose files using this `mariadb` are located in https://github.com/MariaDB/mariadb-docker in the `/examples` folder.
# License
View [license information](https://mariadb.com/kb/en/library/licensing-faq/) for the software contained in this image.
As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).
Some additional license information which was able to be auto-detected might be found in [the `repo-info` repository's `mariadb/` directory](https://github.com/docker-library/repo-info/tree/master/repos/mariadb).
As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.
```
--------------------------------------------------------------------------------
/websphere-liberty/README.md:
--------------------------------------------------------------------------------
```markdown
<!--
********************************************************************************
WARNING:
DO NOT EDIT "websphere-liberty/README.md"
IT IS AUTO-GENERATED
(from the other files in "websphere-liberty/" combined with a set of templates)
********************************************************************************
-->
# Quick reference
- **Maintained by**:
[the IBM WASdev Community](https://github.com/WASdev/ci.docker)
- **Where to get help**:
[the WASdev community](https://developer.ibm.com/wasdev/help/)
# Supported tags and respective `Dockerfile` links
- [`kernel`, `kernel-java8-ibmjava`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/latest/kernel/Dockerfile.ubuntu.ibmjava8)
- [`kernel-java11-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/latest/kernel/Dockerfile.ubuntu.openjdk11)
- [`kernel-java17-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/latest/kernel/Dockerfile.ubuntu.openjdk17)
- [`full`, `latest`, `full-java8-ibmjava`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/latest/full/Dockerfile.ubuntu.ibmjava8)
- [`full-java11-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/latest/full/Dockerfile.ubuntu.openjdk11)
- [`full-java17-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/latest/full/Dockerfile.ubuntu.openjdk17)
- [`24.0.0.12-kernel-java8-ibmjava`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/24.0.0.12/kernel/Dockerfile.ubuntu.ibmjava8)
- [`24.0.0.12-kernel-java11-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/24.0.0.12/kernel/Dockerfile.ubuntu.openjdk11)
- [`24.0.0.12-kernel-java17-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/24.0.0.12/kernel/Dockerfile.ubuntu.openjdk17)
- [`24.0.0.12-full-java8-ibmjava`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/24.0.0.12/full/Dockerfile.ubuntu.ibmjava8)
- [`24.0.0.12-full-java11-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/24.0.0.12/full/Dockerfile.ubuntu.openjdk11)
- [`24.0.0.12-full-java17-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/24.0.0.12/full/Dockerfile.ubuntu.openjdk17)
- [`25.0.0.3-kernel-java8-ibmjava`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.3/kernel/Dockerfile.ubuntu.ibmjava8)
- [`25.0.0.3-kernel-java11-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.3/kernel/Dockerfile.ubuntu.openjdk11)
- [`25.0.0.3-kernel-java17-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.3/kernel/Dockerfile.ubuntu.openjdk17)
- [`25.0.0.3-full-java8-ibmjava`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.3/full/Dockerfile.ubuntu.ibmjava8)
- [`25.0.0.3-full-java11-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.3/full/Dockerfile.ubuntu.openjdk11)
- [`25.0.0.3-full-java17-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.3/full/Dockerfile.ubuntu.openjdk17)
- [`25.0.0.4-kernel-java8-ibmjava`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.4/kernel/Dockerfile.ubuntu.ibmjava8)
- [`25.0.0.4-kernel-java11-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.4/kernel/Dockerfile.ubuntu.openjdk11)
- [`25.0.0.4-kernel-java17-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.4/kernel/Dockerfile.ubuntu.openjdk17)
- [`25.0.0.4-full-java8-ibmjava`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.4/full/Dockerfile.ubuntu.ibmjava8)
- [`25.0.0.4-full-java11-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.4/full/Dockerfile.ubuntu.openjdk11)
- [`25.0.0.4-full-java17-openj9`](https://github.com/WASdev/ci.docker/blob/39ee1440e2dc942c6978eb56f2ae09a2213218dd/ga/25.0.0.4/full/Dockerfile.ubuntu.openjdk17)
# Quick reference (cont.)
- **Where to file issues**:
[https://github.com/WASdev/ci.docker/issues](https://github.com/WASdev/ci.docker/issues?q=)
- **Supported architectures**: ([more info](https://github.com/docker-library/official-images#architectures-other-than-amd64))
[`amd64`](https://hub.docker.com/r/amd64/websphere-liberty/), [`arm64v8`](https://hub.docker.com/r/arm64v8/websphere-liberty/), [`ppc64le`](https://hub.docker.com/r/ppc64le/websphere-liberty/), [`s390x`](https://hub.docker.com/r/s390x/websphere-liberty/)
- **Published image artifact details**:
[repo-info repo's `repos/websphere-liberty/` directory](https://github.com/docker-library/repo-info/blob/master/repos/websphere-liberty) ([history](https://github.com/docker-library/repo-info/commits/master/repos/websphere-liberty))
(image metadata, transfer size, etc)
- **Image updates**:
[official-images repo's `library/websphere-liberty` label](https://github.com/docker-library/official-images/issues?q=label%3Alibrary%2Fwebsphere-liberty)
[official-images repo's `library/websphere-liberty` file](https://github.com/docker-library/official-images/blob/master/library/websphere-liberty) ([history](https://github.com/docker-library/official-images/commits/master/library/websphere-liberty))
- **Source of this description**:
[docs repo's `websphere-liberty/` directory](https://github.com/docker-library/docs/tree/master/websphere-liberty) ([history](https://github.com/docker-library/docs/commits/master/websphere-liberty))
# Overview
All of the images in this repository use Ubuntu as the Operating System. For variants that use the Universal Base Image, please see [this repository](https://hub.docker.com/r/ibmcom/websphere-liberty/).
For more information on these images please see our [GitHub repository](https://github.com/WASdev/ci.docker#container-images).
# Image User
This image runs by default with `USER 1001` (non-root), as part of group `0`. Please make sure you read below to set the appropriate folder and file permissions.
## Updating folder permissions
All of the folders accessed by WebSphere Liberty have been given the appropriate permissions, but if your extending Dockerfile needs permission to another location you can simply temporarily switch into root and provide the needed permissions, example:
```dockerfile
USER root
RUN mkdir -p /myFolder && chown -R 1001:0 /myFolder
USER 1001
```
## Updating file permissions
You have to make sure that **all** the artifacts you are copying into the image (via `COPY` or `ADD`) have the correct permissions to be `read` and `executed` by user `1001` or group `0`, because the ownership of the file is changed to be `root:0` when transferring into the docker image.
You have a few options for doing this: before copying the file, during copy, or after copy.
### Updating permissions before copying
Since the ownership of the file will change to `root:0`, you can simply set the permissions for the owner's group to be able to read/execute the artifact (i.e. the middle digit of a `chmod` command). For example, you can do `chmod g+rx server.xml` to ensure your `server.xml` can be `read` and `executed` by group `0`, as well as any artifacts such as the application's `EAR` or `WAR` file, JDBC driver, or other files that are placed on the image via `COPY` or `ADD`.
### Updating permissions during copy
If you're using Docker v17.09.0-ce and newer you can take advantage of the flag `--chown=<user>:<group>` during either `ADD` or `COPY`. For example: `COPY --chown=1001:0 jvm.options /config/jvm.options`. This is the preferred approach as you don't need to worry about changing permissions before calling `docker build` and you also do not duplicate layers in the resulting image.
### Updating permissions after copy
If you need your Dockerfile to work with older versions of Docker CE and don't want to pre-process the permissions of the files you can temporarily switch into root to change the permissions of the needed files. For example:
```dockerfile
USER root
RUN chown 1001:0 /config/jvm.options
RUN chown 1001:0 /output/resources/security/ltpa.keys
USER 1001
```
Please note that this pattern will duplicate the docker layers for those artifacts, which can heavily bloat your resulting docker image (depending on the size of the artifact). So it is recommended to set the permissions before or during copy.
# Tags
There are multiple tags available in this repository. The image with the tag `beta` contains the contents of the install archive for the latest monthly beta. The other images are all based on the latest generally available fix pack.
The `kernel` image contains just the Liberty kernel and no additional runtime features. This image is the recommended basis for custom built images, so that they can contain only the features required for a specific application. For example, the following Dockerfile starts with this image, copies in the `server.xml` that lists the features required by the application, and then uses the `configure.sh` script to download those features from the online repository.
```dockerfile
FROM websphere-liberty:kernel
COPY --chown=1001:0 Sample1.war /config/dropins/
COPY --chown=1001:0 server.xml /config/
RUN configure.sh
```
# Usage
The images are designed to support a number of different usage patterns. The following examples are based on the Java EE8 Liberty [application deployment sample](https://developer.ibm.com/wasdev/docs/article_appdeployment/) and assume that [DefaultServletEngine.zip](https://github.com/WASdev/sample.servlet/releases/download/V1/DefaultServletEngine.zip) has been extracted to `/tmp` and the `server.xml` updated to accept HTTP connections from outside of the container by adding the following element inside the `server` stanza (if not using one of the pre-packaged `server.xml` files with our tags):
```xml
<httpEndpoint host="*" httpPort="9080" httpsPort="-1"/>
```
## Application Image
It is a very strong best practice to create an extending Docker image, we called it the `application image`, that encapsulates an application and its configuration. This creates a robust, self-contained and predictable Docker image that can span new containers upon request, without relying on volumes or other external runtime artifacts that may behave different over time.
If you want to build the smallest possible WebSphere Liberty application image you can start with our `kernel` tag, add your artifacts, and run `configure.sh` to grow the set of features to be fit-for-purpose. Please see our [GitHub page](https://github.com/WASdev/ci.docker#building-an-application-image) for more details.
## Enabling Enterprise functionality
The WebSphere Liberty images have a set of built-in XML snippets that enable and configure enterprise functionality such as session cache and monitoring. These are toggled by specific `ARG`s in your application image Dockerfile and configured via the `configure.sh` script. Please see the [instructions](https://github.com/wasdev/ci.docker#enterprise-functionality) on our GitHub page for more information.
## Using volumes for configuration
This pattern can be useful for quick experiments / early development (i.e. `I just want to run the application as I iterate over it`), but should not be used for development scenarios that involve different teams and environments - for these cases the `Application Image` pattern described above is the way to go.
When using `volumes`, an application file can be mounted in the `dropins` directory of this server and run. The following example starts a container in the background running a .WAR file from the host file system with the HTTP and HTTPS ports mapped to 80 and 443 respectively.
```console
$ docker run -d -p 80:9080 -p 443:9443 \
-v /tmp/DefaultServletEngine/dropins/Sample1.war:/config/dropins/Sample1.war \
websphere-liberty:webProfile8
```
When the server is started, you can browse to http://localhost/Sample1/SimpleServlet on the Docker host.
Note: If you are using the boot2docker virtual machine on OS X or Windows, you need to get the IP of the virtual host by using the command `boot2docker ip` instead of by using localhost.
For greater flexibility over configuration, it is possible to mount an entire server configuration directory from the host and then specify the server name as a parameter to the run command. Note: This particular example server configuration provides only HTTP access.
```console
$ docker run -d -p 80:9080 \
-v /tmp/DefaultServletEngine:/config \
websphere-liberty:webProfile8
```
# Using Spring Boot with WebSphere Liberty
The `full` images introduce capabilities specific to the support of all Liberty features, including Spring Boot applications. This image thus includes the `springBootUtility` used to separate Spring Boot applications into thin applications and dependency library caches. To get these same capabilities without including features you are not using, build instead on top of `kernel` images and run configure.sh for your server.xml, ensuring that it enables either the `springBoot-1.5` or `springBoot-2.0` feature.
To elaborate these capabilities this section assumes the standalone Spring Boot 2.0.x application `hellospringboot.jar` exists in the `/tmp` directory.
1. A Spring Boot application JAR deploys to the `dropins/spring` directory within the default server configuration, not the `dropins` directory. Liberty allows one Spring Boot application per server configuration. You can create a Spring Boot application layer over this image by adding the application JAR to the `dropins/spring` directory. In this example we copied `hellospringboot.jar` from `/tmp` to the same directory containing the following Dockerfile.
```dockerfile
FROM websphere-liberty:kernel
COPY --chown=1001:0 hellospringboot.jar /config/dropins/spring/
COPY --chown=1001:0 server.xml /config/
RUN configure.sh
```
The custom image can be built and run as follows.
```console
$ docker build -t app .
$ docker run -d -p 8080:9080 app
```
2. The `full` images provide the library cache directory, `lib.index.cache`, which contains an indexed library cache created by the `springBootUtility` command. Use `lib.index.cache` to provide the library cache for a thin application.
You can use the `springBootUtility` command to create thin application and library cache layers over a `full` image. The following example uses docker staging to efficiently build an image that deploys a fat Spring Boot application as two layers containing a thin application and a library cache.
```dockerfile
FROM websphere-liberty:kernel as staging
COPY --chown=1001:0 hellospringboot.jar /staging/myFatApp.jar
COPY --chown=1001:0 server.xml /config/
RUN springBootUtility thin \
--sourceAppPath=/staging/myFatApp.jar \
--targetThinAppPath=/staging/myThinApp.jar \
--targetLibCachePath=/staging/lib.index.cache
FROM websphere-liberty:kernel
COPY --chown=1001:0 server.xml /config
COPY --from=staging /staging/lib.index.cache /lib.index.cache
COPY --from=staging /staging/myThinApp.jar /config/dropins/spring/myThinApp.jar
RUN configure.sh
```
For Spring Boot applications packaged with library dependencies that rarely change across continuous application updates, you can use the capabilities mentioned above to to share library caches across containers and to create even more efficient docker layers that leverage the docker build cache.
# Providing your own keystore/truststore
By default, when a `websphere-liberty` image starts, a Liberty server XML snippet is generated in `/config/configDropins/defaults/keystore.xml` that specifies a `keyStore` stanza with a generated password. This causes Liberty to generate a default keystore and truststore with a self-signed certificate when it starts (see the [Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/rwlp_liberty_ssl_defaults.html) for more information). When providing your own keystore/truststore, this default behavior can be disabled by ensuring that a file already exists at `/config/configDropins/defaults/keystore.xml` (for example, added as part of your Docker build). This file can contain your keystore configuration or could just contain an empty `<server></server>` stanza.
# Using IBM JRE Class data sharing
The IBM JRE provides a feature [Class data sharing](http://www-01.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.lnx.80.doc/diag/understanding/shared_classes.html) which offers transparent and dynamic sharing of data between multiple Java Virtual Machines running on the same host by using shared memory backed by a file. When running the Liberty Docker image, it looks for the file at `/opt/ibm/wlp/output/.classCache`. To benefit from Class data sharing, this location needs to be shared between containers either through the host or a data volume container.
Taking the application image from example 3 above, containers can share the host file location (containing the shared cache) `/tmp/websphere-liberty/classCache` as follows:
```console
docker run -d -p 80:9080 -p 443:9443 \
-v /tmp/websphere-liberty/classCache:/opt/ibm/wlp/output/.classCache app
```
Or, create a named data volume container that exposes a volume at the location of the shared file:
```console
docker run -e LICENSE=accept -v /opt/ibm/wlp/output/.classCache \
--name classcache websphere-liberty true
```
Then, run the WebSphere Liberty image with the volumes from the data volume container classcache mounted as follows:
```console
docker run -d -p 80:9080 -p 443:9443 --volumes-from classcache app
```
# Running WebSphere Liberty in read-only mode
Liberty writes to two different directories when running: `/opt/ibm/wlp/output` and `/logs`. In order to run the Liberty image in read-only mode these may be mounted as temporary file systems. If using the provided image, the keystore will be generated on initial start up in the server configuration. This means that the server configuration directory either needs to be read-write or the keystore will need to be built into the image. In the example command `/config` is mounted as a read-write volume.
```console
docker run -d -p 80:9080 -p 443:9443 \
--tmpfs /opt/ibm/wlp/output --tmpfs /logs -v /config --read-only \
websphere-liberty:javaee8
```
# Changing locale
The base Ubuntu image does not include additional language packs. To use an alternative locale, build your own image that installs the required language pack and then sets the `LANG` environment variable. For example, the following Dockerfile starts with the `websphere-liberty:full` image, installs the Portuguese language pack, and sets Brazilian Portuguese as the default locale:
```dockerfile
FROM websphere-liberty:full
RUN apt-get update \
&& apt-get install -y language-pack-pt-base \
&& rm -rf /var/lib/apt/lists/*
ENV LANG pt_BR.UTF-8
```
# License
The Dockerfiles and associated scripts are licensed under the [Apache License 2.0](http://www.apache.org/licenses/LICENSE-2.0.html).
Starting with WebSphere Liberty 18.0.0.3, the WebSphere Liberty Docker images found in Docker Hub contain an International License Agreement for Non-Warranted Programs (ILAN) license which allows entitled WebSphere Liberty customers to use these same images under an International Program License Agreement (IPLA) term.
For customers that still wish to apply a WebSphere Application Server license to their docker image can do so following [these instructions](https://github.com/WASdev/ci.docker/tree/master/ga/production-upgrade).
As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).
Some additional license information which was able to be auto-detected might be found in [the `repo-info` repository's `websphere-liberty/` directory](https://github.com/docker-library/repo-info/tree/master/repos/websphere-liberty).
As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.
```
--------------------------------------------------------------------------------
/friendica/README.md:
--------------------------------------------------------------------------------
```markdown
<!--
********************************************************************************
WARNING:
DO NOT EDIT "friendica/README.md"
IT IS AUTO-GENERATED
(from the other files in "friendica/" combined with a set of templates)
********************************************************************************
-->
# Quick reference
- **Maintained by**:
[nupplaPhil](https://github.com/friendica/docker)
- **Where to get help**:
[the Docker Community Slack](https://dockr.ly/comm-slack), [Server Fault](https://serverfault.com/help/on-topic), [Unix & Linux](https://unix.stackexchange.com/help/on-topic), or [Stack Overflow](https://stackoverflow.com/help/on-topic)
# Supported tags and respective `Dockerfile` links
- [`2024.12-apache`, `apache`, `stable-apache`, `2024.12`, `latest`, `stable`](https://github.com/friendica/docker/blob/e56a5124cbf9b88e01f0ebeab0b20d6dfeb25f10/2024.12/apache/Dockerfile)
- [`2024.12-fpm`, `fpm`, `stable-fpm`](https://github.com/friendica/docker/blob/ae4df4f198515a27ab160bd3679cf91183a17cce/2024.12/fpm/Dockerfile)
- [`2024.12-fpm-alpine`, `fpm-alpine`, `stable-fpm-alpine`](https://github.com/friendica/docker/blob/ae4df4f198515a27ab160bd3679cf91183a17cce/2024.12/fpm-alpine/Dockerfile)
- [`2025.02-dev-apache`, `dev-apache`, `2025.02-dev`, `dev`](https://github.com/friendica/docker/blob/e56a5124cbf9b88e01f0ebeab0b20d6dfeb25f10/2025.02-dev/apache/Dockerfile)
- [`2025.02-dev-fpm`, `dev-fpm`](https://github.com/friendica/docker/blob/ae4df4f198515a27ab160bd3679cf91183a17cce/2025.02-dev/fpm/Dockerfile)
- [`2025.02-dev-fpm-alpine`, `dev-fpm-alpine`](https://github.com/friendica/docker/blob/ae4df4f198515a27ab160bd3679cf91183a17cce/2025.02-dev/fpm-alpine/Dockerfile)
# Quick reference (cont.)
- **Where to file issues**:
[https://github.com/friendica/docker/issues](https://github.com/friendica/docker/issues?q=)
- **Supported architectures**: ([more info](https://github.com/docker-library/official-images#architectures-other-than-amd64))
[`amd64`](https://hub.docker.com/r/amd64/friendica/), [`arm32v5`](https://hub.docker.com/r/arm32v5/friendica/), [`arm32v6`](https://hub.docker.com/r/arm32v6/friendica/), [`arm32v7`](https://hub.docker.com/r/arm32v7/friendica/), [`arm64v8`](https://hub.docker.com/r/arm64v8/friendica/), [`i386`](https://hub.docker.com/r/i386/friendica/), [`mips64le`](https://hub.docker.com/r/mips64le/friendica/), [`ppc64le`](https://hub.docker.com/r/ppc64le/friendica/), [`riscv64`](https://hub.docker.com/r/riscv64/friendica/), [`s390x`](https://hub.docker.com/r/s390x/friendica/)
- **Published image artifact details**:
[repo-info repo's `repos/friendica/` directory](https://github.com/docker-library/repo-info/blob/master/repos/friendica) ([history](https://github.com/docker-library/repo-info/commits/master/repos/friendica))
(image metadata, transfer size, etc)
- **Image updates**:
[official-images repo's `library/friendica` label](https://github.com/docker-library/official-images/issues?q=label%3Alibrary%2Ffriendica)
[official-images repo's `library/friendica` file](https://github.com/docker-library/official-images/blob/master/library/friendica) ([history](https://github.com/docker-library/official-images/commits/master/library/friendica))
- **Source of this description**:
[docs repo's `friendica/` directory](https://github.com/docker-library/docs/tree/master/friendica) ([history](https://github.com/docker-library/docs/commits/master/friendica))
# What is Friendica?
Friendica is a decentralised communications platform that integrates social communication. Our platform links to independent social projects and corporate services.
# How to use this image
The images are designed to be used in a micro-service environment. There are two types of the image you can choose from.
The `apache` tag contains a full Friendica installation including an apache web server. It is designed to be easy to use and gets you running pretty fast. This is also the default for the `latest` tag and version tags that are not further specified.
The second option is a `fpm` container. It is based on the [php-fpm](https://hub.docker.com/_/php/) image and runs a fastCGI-Process that serves your Friendica server. To use this image it must be combined with any Webserver that can proxy the http requests to the FastCGI-port of the container.
## Using the apache image
You need at least one other mariadb/mysql-container to link it to Friendica.
The apache image contains a webserver and exposes port 80. To start the container type:
```console
$ docker run -d -p 8080:80 --network some-network friendica
```
Now you can access the Friendica installation wizard at http://localhost:8080/ from your host system.
## Using the fpm image
To use the fpm image you need an additional web server that can proxy http-request to the fpm-port of the container. For fpm connection this container exposes port 9000. In most cases you might want use another container or your host as proxy. If you use your host you can address your Friendica container directly on port 9000. If you use another container, make sure that you add them to the same docker network (via `docker run --network <NAME> ...` or a `compose.yaml` file). In both cases you don't want to map the fpm port to you host.
```console
$ docker run -d friendica:fpm
```
As the fastCGI-Process is not capable of serving static files (style sheets, images, ...) the webserver needs access to these files. This can be achieved with the `volumes-from` option. You can find more information in the Docker Compose section.
## Background tasks
Friendica requires background tasks to fetch and send all kind of messages and maintain the complete instance. This setup is crucial for the Friendica node. There are two options to enable background tasks for Friendica:
- Using the default Image and manually setup background tasks (see Friendica [Install](https://github.com/friendica/friendica/blob/2021.03-rc/doc/Install.md#required-background-tasks))
- Using the default image (apache, fpm, fpm-alpine) and starting a dedicated `cron` instance and use `cron.sh` as startup command (like this [Example](https://github.com/friendica/docker/blob/stable/.examples/docker-compose/insecure/mariadb-cron-redis/apache/docker-compose.yml))
## Possible Environment Variables
**Friendica Settings**
- `FRIENDICA_URL` The Friendica complete URL including protocol, domain and subpath (example: https://friendica.local/sub/ ).
- `FRIENDICA_TZ` The default localization of the Friendica server.
- `FRIENDICA_LANG` The default language of the Friendica server.
- `FRIENDICA_SITENAME` The Sitename of the Friendica server.
- `FRIENDICA_NO_VALIDATION` If set to `true`, the URL and E-Mail validation will be disabled.
- `FRIENDICA_DATA` Set the name of the storage provider (e.g `Filesystem` to use filesystem), default ist the DB backend.
- `FRIENDICA_DATA_DIR` The data directory of the Friendica server (Default: /var/www/data).
- `FRIENDICA_UPGRADE` Force starting the Friendica update even it's the same version (Default: `false`).
**Friendica Logging**
- `FRIENDICA_DEBUGGING` If set to `true`, the logging of Friendica is enabled.
- `FRIENDICA_LOGFILE` (optional) The path to the logfile (Default: /var/www/friendica.log).
- `FRIENDICA_LOGLEVEL` (optional) The loglevel to log (Default: notice).
- `FRIENDICA_LOGGER` (optional) Set the type - stream, syslog, monolog (Default: stream).
- `FRIENDICA_SYSLOG_FLAGS` (optional) In case syslog is used, set the corresponding flags (Default: `LOG_PID | LOG_ODELAY | LOG_CONS | LOG_PERROR`).
- `FRIENDICA_SYSLOG_FACTORY` (optional) In case syslog is used, set the corresponding factory (Default: `LOG_USER`).
**Database** (**required at installation**)
- `MYSQL_USER` Username for the database user using mysql / mariadb.
- `MYSQL_PASSWORD` Password for the database user using mysql / mariadb.
- `MYSQL_DATABASE` Name of the database using mysql / mariadb.
- `MYSQL_HOST` Hostname of the database server using mysql / mariadb.
- `MYSQL_PORT` Port of the database server using mysql / mariadb (Default: `3306`)
**Lock Driver (Redis)**
- `REDIS_HOST` The hostname of the redis instance (in case of locking).
- `REDIS_PORT` (optional) The port of the redis instance (in case of locking).
- `REDIS_PW` (optional) The password for the redis instance (in case of locking).
- `REDIS_DB` (optional) The database instance of the redis instance (in case of locking).
**PHP limits**
- `PHP_MEMORY_LIMIT` (default `512M`) This sets the maximum amount of memory in bytes that a script is allowed to allocate. This is meant to help prevent poorly written scripts from eating up all available memory, but it can prevent normal operation if set too tight.
- `PHP_UPLOAD_LIMIT` (default `512M`) This sets the upload limit (`post_max_size` and `upload_max_filesize`) for big files. Note that you may have to change other limits depending on your client, webserver or operating system.
## Administrator account
Because Friendica links the administrator account to a specific mail address, you **have** to set a valid address for `MAILNAME`.
## Mail settings
The binary `ssmtp` is used for the `mail()` support of Friendica.
You have to set the `--hostname/-h` parameter correctly to use the right domainname for the `mail()` command.
You have to set a valid SMTP-MTA for the `SMTP` environment variable to enable mail support in Friendica. A valid SMTP-MTA would be, for example, `mx.example.org`.
The following environment variables are possible for the SMTP examples.
- `SMTP` Address of the SMTP Mail-Gateway. (**required**)
- `SMTP_PORT` Port of the SMTP Mail-Gateway. (Default: 587)
- `SMTP_DOMAIN` The sender domain. (**required** - e.g. `friendica.local`)
- `SMTP_FROM` Sender user-part of the address. (Default: `no-reply` - e.g. [email protected])
- `SMTP_TLS` Use TLS for connecting the SMTP Mail-Gateway. (Default: empty)
- `SMTP_STARTTLS` Use STARTTLS for connecting the SMTP Mail-Gateway. (Default: `On`)
- `SMTP_AUTH` Auth mode for the SMTP Mail-Gateway. (Default: `On`)
- `SMTP_AUTH_USER` Username for the SMTP Mail-Gateway. (Default: empty)
- `SMTP_AUTH_PASS` Password for the SMTP Mail-Gateway. (Default: empty)
**Addition to STARTTLS**
the `tls_starttls` setting is either `On` or `Off`, but never unset. That's because in case it's unset, `starttls` would be activated by default (which would need additional configuration like a separate port).
## Database settings
You have to add the Friendica container to the same network as the running database container, e. g. `--network some-network`, and then use `mysql` as the database host on setup.
## Persistent data
The Friendica installation and all data beyond what lives in the database (file uploads, etc) is stored in the [unnamed docker volume](https://docs.docker.com/storage/volumes/) volume `/var/www/html`. The docker daemon will store that data within the docker directory `/var/lib/docker/volumes/...`. That means your data is saved even if the container crashes, is stopped or deleted. To make your data persistent to upgrading and get access for backups is using named docker volume or mount a host folder. To achieve this you need one volume for your database container and Friendica.
Friendica:
- `/var/www/html/` folder where all Friendica data lives
```console
$ docker run -d \
-v friendica-vol-1:/var/www/html \
--network some-network
friendica
```
Database:
- `/var/lib/mysql` MySQL / MariaDB Data
```console
$ docker run -d \
-v mysql-vol-1:/var/lib/mysql \
--network some-network
mariadb
```
## Automatic installation
The Friendica image supports auto configuration via environment variables. You can preconfigure everything that is asked on the install page on first run. To enable the automatic installation, you have to the following environment variables:
- `FRIENDICA_URL` The Friendica complete URL including protocol, domain and subpath (example: https://friendica.local/sub/ ).
- `FRIENDICA_ADMIN_MAIL` E-Mail address of the administrator.
- `MYSQL_USER` Username for the database user using mysql / mariadb.
- `MYSQL_PASSWORD` Password for the database user using mysql / mariadb.
- `MYSQL_DATABASE` Name of the database using mysql / mariadb.
- `MYSQL_HOST` Hostname of the database server using mysql / mariadb.
# Docker Secrets
As an alternative to passing sensitive information via environment variables, _FILE may be appended to the previously listed environment variables, causing the initialization script to load the values for those variables from files present in the container. In particular, this can be used to load passwords from Docker secrets stored in /run/secrets/<secret_name> files. For example:
```yaml
services:
db:
image: mariadb
restart: always
volumes:
- db:/var/lib/mysql
environment:
- MYSQL_DATABASE_FILE=/run/secrets/mysql_database
- MYSQL_USER_FILE=/run/secrets/mysql_user
- MYSQL_PASSWORD_FILE=/run/secrets/mysql_password
secrets:
- mysql_database
- mysql_password
- mysql_user
app:
image: friendica
restart: always
volumes:
- friendica:/var/www/html
ports:
- "8080:80"
environment:
- MYSQL_HOST=db
- MYSQL_DATABASE_FILE=/run/secrets/mysql_database
- MYSQL_USER_FILE=/run/secrets/mysql_user
- MYSQL_PASSWORD_FILE=/run/secrets/mysql_password
- FRIENDICA_ADMIN_MAIL_FILE=/run/secrets/friendica_admin_mail
depends_on:
- db
secrets:
- friendica_admin_mail
- mysql_database
- mysql_password
- mysql_user
volumes:
db:
friendica:
secrets:
friendica_admin_mail:
file: ./friendica_admin_mail.txt # put admin email to this file
mysql_database:
file: ./mysql_database.txt # put mysql database name to this file
mysql_password:
file: ./mysql_password.txt # put mysql password to this file
mysql_user:
file: ./mysql_user.txt # put mysql username to this file
```
Currently, this is only supported for `FRIENDICA_ADMIN_MAIL`, `MYSQL_DATABASE`, `MYSQL_PASSWORD`, `MYSQL_USER`.
# Maintenance of the image
## Updating to a newer version
You have to pull the latest image from the hub (`docker pull friendica`). The stable branch gets checked at every startup and will get updated if no installation was found or a new image is used.
# Running this image with Docker Compose
The easiest way to get a fully featured and functional setup is using a `compose.yaml` file. There are too many different possibilities to setup your system, so here are only some examples what you have to look for.
At first make sure you have chosen the right base image (fpm or apache) and added the features you wanted (see below). In every case you want to add a database container and docker volumes to get easy access to your persistent data. When you want your server reachable from the internet adding HTTPS-encryption is mandatory! See below for more information.
## Base version - apache
This version will use the apache image and add a mariaDB container. The volumes are set to keep your data persistent. This setup provides **no ssl encryption** and is intended to run behind a proxy.
Make sure to set the variable `MYSQL_PASSWORD` before run this setup.
```yaml
services:
db:
image: mariadb
restart: always
volumes:
- db:/var/lib/mysql
environment:
- MYSQL_USER=friendica
- MYSQL_PASSWORD=
- MYSQL_DATABASE=friendica
- MYSQL_RANDOM_ROOT_PASSWORD=yes
app:
image: friendica
restart: always
volumes:
- friendica:/var/www/html
ports:
- "8080:80"
environment:
- MYSQL_HOST=db
- MYSQL_USER=friendica
- MYSQL_PASSWORD=
- MYSQL_DATABASE=friendica
- [email protected]
depends_on:
- db
volumes:
db:
friendica:
```
Then run `docker compose up -d`, now you can access Friendica at http://localhost:8080/ from your system.
## Base version - FPM
When using the FPM image you need another container that acts as web server on port 80 and proxies requests to the Friendica container. In this example a simple nginx container is combined with the Friendica-fpm image and a MariaDB database container. The data is stored in docker volumes. The nginx container also need access to static files from your Friendica installation. It gets access to all the volumes mounted to Friendica via the `volumes_from` option. The configuration for nginx is stored in the configuration file `nginx.conf` that is mounted into the container.
An example can be found in the [examples section](https://github.com/friendica/docker/tree/master/.examples).
As this setup does **not include encryption** it should to be run behind a proxy.
Prerequisites for this example:
- Make sure to set the variable `MYSQL_PASSWORD` and `MYSQL_USER` before you run the setup.
- Create a `nginx.conf` in the same directory as the `compose.yaml` file (take it from [example](https://github.com/friendica/docker/tree/master/.examples/docker-compose/with-traefik-proxy/mariadb-cron-smtp/fpm/web/nginx.conf))
```yaml
services:
db:
image: mariadb
restart: always
volumes:
- db:/var/lib/mysql
environment:
- MYSQL_USER=friendica
- MYSQL_PASSWORD=
- MYSQL_DATABASE=friendica
- MYSQL_RANDOM_ROOT_PASSWORD=yes
app:
image: friendica:fpm
restart: always
volumes:
- friendica:/var/www/html
environment:
- MYSQL_HOST=db
- MYSQL_USER=friendica
- MYSQL_PASSWORD=
- MYSQL_DATABASE=friendica
- [email protected]
networks:
- proxy-tier
- default
web:
image: nginx
ports:
- 8080:80
links:
- app
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
restart: always
networks:
- proxy-tier
volumes:
db:
friendica:
networks:
proxy-tier:
```
Then run `docker compose up -d`, now you can access Friendica at http://localhost:8080/ from your system.
# Special settings for DEV/RC images
The `*-dev` and `*-rc` branches are directly downloaded and verified at each docker start to ensure that the latest sources are used. The parameter `FRIENDICA_UPGRADE` is required to be `true` (Default: `false`) to activate this behavior.
# Questions / Issues
If you got any questions or problems using the image, please visit our [Github Repository](https://github.com/friendica/docker) and write an issue.
# Image Variants
The `friendica` images come in many flavors, each designed for a specific use case.
## `friendica:<version>`
This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
## `friendica:<version>-alpine`
This image is based on the popular [Alpine Linux project](https://alpinelinux.org), available in [the `alpine` official image](https://hub.docker.com/_/alpine). Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.
This variant is useful when final image size being as small as possible is your primary concern. The main caveat to note is that it does use [musl libc](https://musl.libc.org) instead of [glibc and friends](https://www.etalabs.net/compare_libcs.html), so software will often run into issues depending on the depth of their libc requirements/assumptions. See [this Hacker News comment thread](https://news.ycombinator.com/item?id=10782897) for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.
To minimize image size, it's uncommon for additional related tools (such as `git` or `bash`) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the [`alpine` image description](https://hub.docker.com/_/alpine/) for examples of how to install packages if you are unfamiliar).
# License
View [license information](https://github.com/friendica/server/blob/master/LICENSE) for the software contained in this image.
As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).
Some additional license information which was able to be auto-detected might be found in [the `repo-info` repository's `friendica/` directory](https://github.com/docker-library/repo-info/tree/master/repos/friendica).
As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.
```
--------------------------------------------------------------------------------
/geonetwork/README.md:
--------------------------------------------------------------------------------
```markdown
<!--
********************************************************************************
WARNING:
DO NOT EDIT "geonetwork/README.md"
IT IS AUTO-GENERATED
(from the other files in "geonetwork/" combined with a set of templates)
********************************************************************************
-->
# Quick reference
- **Maintained by**:
[GeoNetwork opensource](https://github.com/geonetwork/docker-geonetwork)
- **Where to get help**:
[the Docker Community Slack](https://dockr.ly/comm-slack), [Server Fault](https://serverfault.com/help/on-topic), [Unix & Linux](https://unix.stackexchange.com/help/on-topic), or [Stack Overflow](https://stackoverflow.com/help/on-topic)
# Supported tags and respective `Dockerfile` links
- [`3.12.12`, `3.12`, `3`](https://github.com/geonetwork/docker-geonetwork/blob/17278beab34080c90454c0b7059bd6b49701f979/3.12.12/Dockerfile)
- [`3.12.12-postgres`, `3.12-postgres`, `3-postgres`](https://github.com/geonetwork/docker-geonetwork/blob/17278beab34080c90454c0b7059bd6b49701f979/3.12.12/postgres/Dockerfile)
- [`4.2.12`, `4.2`](https://github.com/geonetwork/docker-geonetwork/blob/a3e15b94330e69449238b4bb0c6e6909f958afa2/4.2.12/Dockerfile)
- [`4.4.7`, `4.4`, `4`, `latest`](https://github.com/geonetwork/docker-geonetwork/blob/87a25196b8dd3a8a1bd2bc8644f86c878de2b1d4/4.4.7/Dockerfile)
# Quick reference (cont.)
- **Where to file issues**:
[https://github.com/geonetwork/docker-geonetwork/issues](https://github.com/geonetwork/docker-geonetwork/issues?q=)
- **Supported architectures**: ([more info](https://github.com/docker-library/official-images#architectures-other-than-amd64))
[`amd64`](https://hub.docker.com/r/amd64/geonetwork/), [`arm32v7`](https://hub.docker.com/r/arm32v7/geonetwork/), [`arm64v8`](https://hub.docker.com/r/arm64v8/geonetwork/), [`ppc64le`](https://hub.docker.com/r/ppc64le/geonetwork/)
- **Published image artifact details**:
[repo-info repo's `repos/geonetwork/` directory](https://github.com/docker-library/repo-info/blob/master/repos/geonetwork) ([history](https://github.com/docker-library/repo-info/commits/master/repos/geonetwork))
(image metadata, transfer size, etc)
- **Image updates**:
[official-images repo's `library/geonetwork` label](https://github.com/docker-library/official-images/issues?q=label%3Alibrary%2Fgeonetwork)
[official-images repo's `library/geonetwork` file](https://github.com/docker-library/official-images/blob/master/library/geonetwork) ([history](https://github.com/docker-library/official-images/commits/master/library/geonetwork))
- **Source of this description**:
[docs repo's `geonetwork/` directory](https://github.com/docker-library/docs/tree/master/geonetwork) ([history](https://github.com/docker-library/docs/commits/master/geonetwork))
# What is GeoNetwork?
GeoNetwork is a catalog application to **manage spatially referenced resources**. It provides powerful **metadata editing** and **search** functions as well as an interactive **web map viewer**.
The GeoNetwork project started out in year 2001 as a Spatial Data Catalogue System for the Food and Agriculture organisation of the United Nations (FAO), the United Nations World Food Programme (WFP) and the United Nations Environmental Programme (UNEP).
At present the project is widely used as the basis of **Spatial Data Infrastructures** all around the world.
GeoNetwork has been developed to connect spatial information communities and their data using a modern architecture, which is at the same time powerful and low cost, based on the principles of Free and Open Source Software (FOSS) and International and Open Standards for services and protocols (e.g.: ISO/TC211, OGC).
The project is part of the Open Source Geospatial Foundation ( [OSGeo](http://www.osgeo.org/) ) and can be found at [GeoNetwork opensource](http://www.geonetwork-opensource.org). GeoNetwork has been developed to connect spatial information communities and their data using a modern architecture, which is at the same time powerful and low cost.
## How to use this image
GeoNetwork 4 uses an Elasticsearch server to store the index of the documents it manages so **it can't be run without configuring the URL of the Elasticsearch server**.
This is a quick example of how to get GeoNetwork 4.4 Latest up and running for demo purposes. This configuration doesn't keep the data if containers are removed.
```console
docker pull elasticsearch:7.17.15
docker pull geonetwork:4
docker network create gn-network
docker run -d --name my-es-host --network gn-network -e "discovery.type=single-node" elasticsearch:7.17.15
docker run --name geonetwork-host --network gn-network -e GN_CONFIG_PROPERTIES="-Des.host=my-es-host -Des.protocol=http -Des.port=9200 -Des.url=http://my-es-host:9200" -p 8080:8080 geonetwork:4
```
For GeoNetwork 4.2 Stable:
```console
docker pull elasticsearch:7.17.15
docker pull geonetwork:4.2
docker network create gn-network
docker run -d --name my-es-host --network gn-network -e "discovery.type=single-node" elasticsearch:7.17.15
docker run --name geonetwork-host --network gn-network -e ES_HOST=my-es-host -e ES_PROTOCOL=http -e ES_PORT=9200 -p 8080:8080 geonetwork:4.2
```
To be sure about what Elasticsearch version to use you can check the [GeoNetwork documentation](https://docs.geonetwork-opensource.org/4.4/install-guide/installing-index/) for your GN version or the `es.version` property in the [`pom.xml`](https://github.com/geonetwork/core-geonetwork/blob/main/pom.xml#L1528C17-L1528C24) file of the GeoNetwork release used.
### Default credentials
After installation, use the default credentials: **`admin`** (username) and **`admin`** (password). It is recommended to update the default password after installation.
### Elasticsearch configuration
#### Java properties (version 4.4.0 and newer)
Since GeoNetwork 4.4.0, use Java properties passed in the `GN_CONFIG_PROPERTIES` environment variable for Elasticsearch connection configuration:
- `es.host`: *optional* (default `localhost`): The host name of the Elasticsearch server.
- `es.port` *optional* (default `9200`): The port where Elasticsearch server is listening to.
- `es.protocol` *optional* (default `http`): The protocol used to talk to Elasticsearch. Can be `http` or `https`.
- `es.url`: **mandatory if host, port or protocol aren't the default values** (default `http://localhost:9200`): Full URL of the Elasticsearch server.
- `es.index.records` *optional* (default `gn_records`): In case you have more than GeoNetwork instance using the same Elasticsearch cluster each one needs to use a different index name. Use this variable to define the name of the index used by each GeoNetwork.
- `es.username` *optional* (default empty): username used to connect to Elasticsearch.
- `es.password` *optional* (default empty): password used to connect to Elasticsearch.
- `kb.url` *optional* (default `http://localhost:5601`): The URL where Kibana is listening.
Example Docker Compose YAML snippet:
```yaml
services:
geonetwork:
image: geonetwork:4.4
environment:
GN_CONFIG_PROPERTIES: >-
-Des.host=elasticsearch
-Des.protocol=http
-Des.port=9200
-Des.url=http://elasticsearch:9200
-Des.username=my_es_username
-Des.password=my_es_password
-Dkb.url=http://kibana:5601
```
#### Environment variables (version 4.2 and older)
For versions older than 4.4.0, configure Elasticsearch using environment variables:
- `ES_HOST` **mandatory**: The host name of the Elasticsearch server.
- `ES_PORT` *optional* (default `9200`): The port where Elasticsearch server is listening to.
- `ES_PROTOCOL` *optional* (default `http`): The protocol used to talk to Elasticsearch. Can be `http` or `https`.
- `ES_INDEX_RECORDS` *optional* (default `gn_records`): In case you have more than GeoNetwork instance using the same Elasticsearch cluster each one needs to use a different index name. Use this variable to define the name of the index used by each GeoNetwork.
- `ES_USERNAME` *optional* (default empty): username used to connect to Elasticsearch.
- `ES_PASSWORD` *optional* (default empty): password used to connect to Elasticsearch.
- `KB_URL` *Optional* (default `http://localhost:5601`): The URL where Kibana is listening.
### Database configuration
By default GeoNetwork uses a local **H2 database** for demo use (this one is **not recommended for production**). The image contains JDBC drivers for PostgreSQL and MySQL. To configure the database connection use these environment variables:
- `GEONETWORK_DB_TYPE`: The type of database to use. Valid values are `postgres`, `postgres-postgis`, `mysql`. The image can be extended including other drivers and these other types could be used too: `db2`, `h2`, `oracle`, `sqlserver`. The JAR drivers for these other databases would need to be added to `/opt/geonetwork/WEB-INF/lib` mounting them as binds or extending the official image.
- `GEONETWORK_DB_HOST`: The database host name.
- `GEONETWORK_DB_PORT`: The database port.
- `GEONETWORK_DB_NAME`: The database name.
- `GEONETWORK_DB_USERNAME`: The username used to connect to the database.
- `GEONETWORK_DB_PASSWORD`: The password used to connect to the database.
- `GEONETWORK_DB_CONNECTION_PROPERTIES`: Additional properties to be added to the connection string, for example `search_path=test,public&ssl=true` will produce a JDBC connection string like `jdbc:postgresql://localhost:5432/postgres?search_path=test,public&ssl=true`
### Start GeoNetwork
This command will start a debian-based container, running a Tomcat (GN 3) or Jetty (GN 4) web server, with a GeoNetwork WAR deployed on the server:
```console
docker run --name some-geonetwork -d geonetwork
```
### Publish port
GeoNetwork listens on port `8080`. If you want to access the container at the host, **you must publish this port**. For instance, this, will redirect all the container traffic on port 8080, to the same port on the host:
```console
docker run --name some-geonetwork -d -p 8080:8080 geonetwork
```
Then, if you are running docker on Linux, you may access geonetwork at http://localhost:8080/geonetwork.
### Set the data directory and H2 db file
The data directory is the location on the file system where the catalog stores much of its custom configuration and uploaded files. It is also where it stores a number of support files, used for various purposes (e.g.: spatial index, thumbnails). The default variant also uses a local H2 database to store the metadata catalog itself.
By default, GeoNetwork sets the data directory on `/opt/geonetwork/WEB-INF/data` and H2 database file to the Jetty dir `/var/lib/jetty/gn.h2.db` (since GN 4.0.0) or Tomcat `/usr/local/tomcat/gn.h2.db` (for GN 3), but you may override these values by injecting environment variables into the container: - `-e DATA_DIR=...` (defaults to `/opt/geonetwork/WEB-INF/data`) and `-e GEONETWORK_DB_NAME=...` (defaults to `gn` which sets up database `gn.h2.db` in tomcat bin dir `/usr/local/tomcat`). Note that setting the database location via `GEONETWORK_DB_NAME` only works from version 3.10.3 onwards.
Since version 4.4.0 the data directory needs to be configued using Java properties passed in the `GN_CONFIG_PROPERTIES` environment variable. For example:
```console
docker run --name some-geonetwork -d -p 8080:8080 -e GN_CONFIG_PROPERTIES="-Dgeonetwork.dir=/catalogue-data" -e GEONETWORK_DB_NAME=/catalogue-data/db/gn geonetwork
```
### Persisting data
To set the data directory to `/catalogue-data/data` and H2 database file to `/catalogue-data/db/gn.h2.db` so they both persist through restarts:
- GeoNetwork 4.2 and older
```console
docker run --name some-geonetwork -d -p 8080:8080 -e DATA_DIR=/catalogue-data/data -e GEONETWORK_DB_NAME=/catalogue-data/db/gn geonetwork:3
```
- Since GeoNetwork 4.4.0
```console
docker run --name some-geonetwork -d -p 8080:8080 -e GN_CONFIG_PROPERTIES="-Dgeonetwork.dir=/catalogue-data" -e GEONETWORK_DB_NAME=/catalogue-data/db/gn geonetwork
```
If you want the data directory to live beyond restarts, or even destruction of the container, you can mount a directory from the docker engine's host into the container. - `-v /host/path:/path/to/data/directory`. For instance this, will mount the host directory `/host/geonetwork-docker` into `/catalogue-data` on the container:
- GeoNetwork 4.2 and older
```console
docker run --name some-geonetwork -d -p 8080:8080 -e DATA_DIR=/catalogue-data/data -e GEONETWORK_DB_NAME=/catalogue-data/db/gn -v /host/geonetwork-docker:/catalogue-data geonetwork:3
```
- GeoNetwork 4.4.0 and newer
```console
docker run --name some-geonetwork -d -p 8080:8080 -e GN_CONFIG_PROPERTIES="-Dgeonetwork.dir=/catalogue-data" -e GEONETWORK_DB_NAME=/catalogue-data/db/gn -v /host/geonetwork-docker:/catalogue-data geonetwork
```
### ... via [`docker compose`](https://github.com/docker/compose)
Example `compose.yaml` for `geonetwork`:
```yaml
# GeoNetwork
#
# Access via "http://localhost:8080/geonetwork"
#
# Default user: admin
# Default password: admin
volumes:
geonetwork:
esdata:
pgdata:
pglog:
services:
geonetwork:
image: geonetwork:4.4
healthcheck:
test: curl http://localhost:8080/
interval: 5s
timeout: 5s
retries: 30
restart: always
volumes:
- geonetwork:/catalogue-data
depends_on:
database:
condition: service_healthy
ports:
- 8080:8080
environment:
WEBAPP_CONTEXT_PATH: /geonetwork
DATA_DIR: /catalogue-data
TZ: Europe/Amsterdam
JAVA_OPTS: >-
--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
-Djava.security.egd=file:/dev/./urandom -Djava.awt.headless=true
-Xms512M -Xss512M -Xmx2G -XX:+UseConcMarkSweepGC
-Djetty.httpConfig.requestHeaderSize=32768
-Dorg.eclipse.jetty.server.Request.maxFormContentSize=500000
-Dorg.eclipse.jetty.server.Request.maxFormKeys=4000
# For remote debug
# -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
GN_CONFIG_PROPERTIES: >-
-Dgeonetwork.dir=/catalogue-data
-Dgeonetwork.formatter.dir=/catalogue-data/data/formatter
-Dgeonetwork.schema.dir=/opt/geonetwork/WEB-INF/data/config/schema_plugins
-Dgeonetwork.indexConfig.dir=/opt/geonetwork/WEB-INF/data/config/index
-Dgeonetwork.schemapublication.dir=/opt/geonetwork/WEB-INF/data/resources/schemapublication
-Dgeonetwork.htmlcache.dir=/opt/geonetwork/WEB-INF/data/resources/htmlcache
-Des.host=elasticsearch
-Des.protocol=http
-Des.port=9200
-Des.url=http://elasticsearch:9200
-Des.username=
-Des.password=
-Dgeonetwork.ESFeaturesProxy.targetUri=http://elasticsearch:9200/gn-features/{_}
-Dgeonetwork.HttpDashboardProxy.targetUri=http://kibana:5601
GEONETWORK_DB_TYPE: postgres-postgis
GEONETWORK_DB_HOST: database
GEONETWORK_DB_PORT: 5432
GEONETWORK_DB_NAME: geonetwork
GEONETWORK_DB_USERNAME: geonetwork
GEONETWORK_DB_PASSWORD: geonetwork
database:
image: postgis/postgis:16-3.4
environment:
POSTGRES_USER: geonetwork
POSTGRES_PASSWORD: geonetwork
POSTGRES_DB: geonetwork
command: [postgres, -c, log_statement=all, -c, logging_collector=true, -c, log_file_mode=0644,
-c, log_directory=/var/log/postgresql, -c, log_filename=postgresql.log]
healthcheck:
test: [CMD-SHELL, pg_isready -U postgres]
interval: 5s
timeout: 5s
retries: 5
volumes:
- pgdata:/var/lib/postgresql/data
- pglog:/var/log/postgresql
elasticsearch:
image: elasticsearch:7.17.15
ports:
- 9200:9200
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536
hard: 65536
healthcheck:
test: curl -s http://localhost:9200 >/dev/null || exit 1
interval: 10s
timeout: 2s
retries: 10
start_period: 2m
environment:
ES_JAVA_OPTS: -Xms1G -Xmx1G
discovery.type: single-node
volumes:
- esdata:/usr/share/elasticsearch/data
kibana:
image: kibana:7.17.15
environment:
SERVER_NAME: kibana
ELASTICSEARCH_URL: http://elasticsearch:9200/
SERVER_BASEPATH: /geonetwork/dashboards
SERVER_REWRITEBASEPATH: 'false'
KIBANA_INDEX: .dashboards
XPACK_MONITORING_UI_CONTAINER_ELASTICSEARCH_ENABLED: 'true'
depends_on:
elasticsearch:
condition: service_healthy
```
Run `docker compose up`, wait for it to initialize completely, and visit `http://localhost:8080/geonetwork` or `http://host-ip:8080/geonetwork` (as appropriate).
### Default credentials
After installation a default user with name `admin` and password `admin` is created. Use this credentials to start with. It is recommended to update the default password after installation.
# Image Variants
The `geonetwork` images come in many flavors, each designed for a specific use case.
## `geonetwork:<version>`
This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
By default, an H2 database is configured and created when the application first starts. If you are interested in a database engine other than H2, please have a look at other image variants.
## `geonetwork:postgres` (Only for GeoNetwork 3 series)
This image gives support for using [PostgreSQL](https://www.postgresql.org/) as database engine for geonetwork. When you start the container, a database is created, and it is populated by geonetwork, once it starts.
Please note that this image **does not ship** the postgres database server itself, but it gives you the option to link to a container running postgres, or to connect to a postgres instance using its ip address. If you are looking for a self-contained installation of geonetwork, **including the database engine**, please have a look at the default image variant.
In order to setup the connection from geonetwork, you **must** inject the following variables into the container: - `POSTGRES_DB_USERNAME`: postgres user on your database server (must have permission to create databases) - `POSTGRES_DB_PASSWORD`: postgres password on your database server
If your postgres instance is listening on a non-standard port, you must also set that variable: - `POSTGRES_DB_PORT`: postgres port on your database server (defaults to `5432`)
### Connecting to a postgres database
If you want to connect to a postgres server, you need to pass an extra environment variable, `POSTGRES_DB_HOST`, containing the address of this server.
If you want to connect to an **external database server**, you can use either the IP address or the DNS as `POSTGRES_DB_HOST`. For instance, if the server is running on `mydns.net`, on port `5434`, the username is `postgres` and the password is `mysecretpassword`:
```console
docker run --name geonetwork -d -p 8080:8080 -e POSTGRES_DB_HOST=mydns.net -e POSTGRES_DB_PORT=5434 -e POSTGRES_DB_USERNAME=postgres -e POSTGRES_DB_PASSWORD=mysecretpassword -e POSTGRES_DB_NAME=mydbname geonetwork:postgres
```
If are want to **run postgres on a container**, you can use the container name as `POSTGRES_DB_HOST`: just make sure that containers can discover each other, by **running them in the same user-defined network**. For instance, you can create a bridge network:
```console
docker network create --driver bridge mynet
```
Then if you want to run the official image of postgres, using `some-postgres` as container name, you could launch it like this:
```console
docker run --name some-postgres --network=mynet -d postgres
```
And then you could launch geonetwork, making sure you join the same network, and setting the required environment variables, including the `POSTGRES_DB_HOST`:
```console
docker run --name geonetwork -d -p 8080:8080 --network=mynet -e POSTGRES_DB_HOST=some-postgres -e POSTGRES_DB_PORT=5432 -e POSTGRES_DB_USERNAME=postgres -e POSTGRES_DB_PASSWORD=mysecretpassword -e POSTGRES_DB_NAME=mydbname geonetwork:postgres
```
#### Configuration environment variables
These are some environments variables that can be set to configure the database connection:
- `POSTGRES_DB_HOST`: database host name.
- `POSTGRES_DB_PORT`: port where database server is listening (by default `5432`).
- `POSTGRES_DB_NAME`: name of the database. If it doesn't exist the container will try to create it.
- `POSTGRES_DB_USERNAME`: username.
- `POSTGRES_DB_PASSWORD`: password.
# License
View [license information](http://www.geonetwork-opensource.org/manuals/trunk/eng/users/overview/license.html) for the software contained in this image.
As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).
Some additional license information which was able to be auto-detected might be found in [the `repo-info` repository's `geonetwork/` directory](https://github.com/docker-library/repo-info/tree/master/repos/geonetwork).
As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.
```
--------------------------------------------------------------------------------
/open-liberty/README.md:
--------------------------------------------------------------------------------
```markdown
<!--
********************************************************************************
WARNING:
DO NOT EDIT "open-liberty/README.md"
IT IS AUTO-GENERATED
(from the other files in "open-liberty/" combined with a set of templates)
********************************************************************************
-->
# Quick reference
- **Maintained by**:
[the Open Liberty Community](https://github.com/OpenLiberty/ci.docker)
- **Where to get help**:
[the Open Liberty community](https://www.openliberty.io/community/)
# Supported tags and respective `Dockerfile` links
- [`beta`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/latest/beta/Dockerfile.ubuntu.openjdk8)
- [`beta-java11`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/latest/beta/Dockerfile.ubuntu.openjdk11)
- [`beta-java17`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/latest/beta/Dockerfile.ubuntu.openjdk17)
- [`kernel-slim`, `kernel-slim-java8-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/latest/kernel-slim/Dockerfile.ubuntu.openjdk8)
- [`kernel-slim-java11-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/latest/kernel-slim/Dockerfile.ubuntu.openjdk11)
- [`kernel-slim-java17-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/latest/kernel-slim/Dockerfile.ubuntu.openjdk17)
- [`full`, `full-java8-openj9`, `latest`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/latest/full/Dockerfile.ubuntu.openjdk8)
- [`full-java11-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/latest/full/Dockerfile.ubuntu.openjdk11)
- [`full-java17-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/latest/full/Dockerfile.ubuntu.openjdk17)
- [`24.0.0.12-kernel-slim-java8-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/24.0.0.12/kernel-slim/Dockerfile.ubuntu.openjdk8)
- [`24.0.0.12-kernel-slim-java11-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/24.0.0.12/kernel-slim/Dockerfile.ubuntu.openjdk11)
- [`24.0.0.12-kernel-slim-java17-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/24.0.0.12/kernel-slim/Dockerfile.ubuntu.openjdk17)
- [`24.0.0.12-full-java8-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/24.0.0.12/full/Dockerfile.ubuntu.openjdk8)
- [`24.0.0.12-full-java11-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/24.0.0.12/full/Dockerfile.ubuntu.openjdk11)
- [`24.0.0.12-full-java17-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/24.0.0.12/full/Dockerfile.ubuntu.openjdk17)
- [`25.0.0.3-kernel-slim-java8-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.3/kernel-slim/Dockerfile.ubuntu.openjdk8)
- [`25.0.0.3-kernel-slim-java11-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.3/kernel-slim/Dockerfile.ubuntu.openjdk11)
- [`25.0.0.3-kernel-slim-java17-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.3/kernel-slim/Dockerfile.ubuntu.openjdk17)
- [`25.0.0.3-full-java8-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.3/full/Dockerfile.ubuntu.openjdk8)
- [`25.0.0.3-full-java11-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.3/full/Dockerfile.ubuntu.openjdk11)
- [`25.0.0.3-full-java17-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.3/full/Dockerfile.ubuntu.openjdk17)
- [`25.0.0.4-kernel-slim-java8-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.4/kernel-slim/Dockerfile.ubuntu.openjdk8)
- [`25.0.0.4-kernel-slim-java11-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.4/kernel-slim/Dockerfile.ubuntu.openjdk11)
- [`25.0.0.4-kernel-slim-java17-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.4/kernel-slim/Dockerfile.ubuntu.openjdk17)
- [`25.0.0.4-full-java8-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.4/full/Dockerfile.ubuntu.openjdk8)
- [`25.0.0.4-full-java11-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.4/full/Dockerfile.ubuntu.openjdk11)
- [`25.0.0.4-full-java17-openj9`](https://github.com/OpenLiberty/ci.docker/blob/ea421dc2f72c32dec2cb226ad9e9d6cfcda38ed0/releases/25.0.0.4/full/Dockerfile.ubuntu.openjdk17)
# Quick reference (cont.)
- **Where to file issues**:
[https://github.com/OpenLiberty/ci.docker/issues](https://github.com/OpenLiberty/ci.docker/issues?q=)
- **Supported architectures**: ([more info](https://github.com/docker-library/official-images#architectures-other-than-amd64))
[`amd64`](https://hub.docker.com/r/amd64/open-liberty/), [`arm64v8`](https://hub.docker.com/r/arm64v8/open-liberty/), [`ppc64le`](https://hub.docker.com/r/ppc64le/open-liberty/), [`s390x`](https://hub.docker.com/r/s390x/open-liberty/)
- **Published image artifact details**:
[repo-info repo's `repos/open-liberty/` directory](https://github.com/docker-library/repo-info/blob/master/repos/open-liberty) ([history](https://github.com/docker-library/repo-info/commits/master/repos/open-liberty))
(image metadata, transfer size, etc)
- **Image updates**:
[official-images repo's `library/open-liberty` label](https://github.com/docker-library/official-images/issues?q=label%3Alibrary%2Fopen-liberty)
[official-images repo's `library/open-liberty` file](https://github.com/docker-library/official-images/blob/master/library/open-liberty) ([history](https://github.com/docker-library/official-images/commits/master/library/open-liberty))
- **Source of this description**:
[docs repo's `open-liberty/` directory](https://github.com/docker-library/docs/tree/master/open-liberty) ([history](https://github.com/docker-library/docs/commits/master/open-liberty))
# Overview
All of the images in this repository use Ubuntu as the Operating System. For variants that use the Universal Base Image, please see [this repository](https://hub.docker.com/r/openliberty/open-liberty/).
For more information on these images please see our [GitHub repository](https://github.com/OpenLiberty/ci.docker#container-images).
# Image User
This image runs by default with `USER 1001` (non-root), as part of group `0`. Please make sure you read below to set the appropriate folder and file permissions.
## Updating folder permissions
All of the folders accessed by Open Liberty have been given the appropriate permissions, but if your extending Dockerfile needs permission to another location you can simply temporarily switch into root and provide the needed permissions, example:
```dockerfile
USER root
RUN mkdir -p /myFolder && chown -R 1001:0 /myFolder
USER 1001
```
## Updating file permissions
You have to make sure that **all** the artifacts you are copying into the image (via `COPY` or `ADD`) have the correct permissions to be `read` and `executed` by user `1001` or group `0`, because the ownership of the file is changed to be `root:0` when transferring into the docker image.
You have a few options for doing this: before copying the file, during copy, or after copy.
### Updating permissions before copying
Since the ownership of the file will change to `root:0`, you can simply set the permissions for the owner's group to be able to read/execute the artifact (i.e. the middle digit of a `chmod` command). For example, you can do `chmod g+rx server.xml` to ensure your `server.xml` can be `read` and `executed` by group `0`, as well as any artifacts such as the application's `EAR` or `WAR` file, JDBC driver, or other files that are placed on the image via `COPY` or `ADD`.
### Updating permissions during copy
If you're using Docker v17.09.0-ce and newer you can take advantage of the flag `--chown=<user>:<group>` during either `ADD` or `COPY`. For example: `COPY --chown=1001:0 jvm.options /config/jvm.options`. This is the preferred approach as you don't need to worry about changing permissions before calling `docker build` and you also do not duplicate layers in the resulting image.
### Updating permissions after copy
If you need your Dockerfile to work with older versions of Docker CE and don't want to pre-process the permissions of the files you can temporarily switch into root to change the permissions of the needed files. For example:
```dockerfile
USER root
RUN chown 1001:0 /config/jvm.options
RUN chown 1001:0 /output/resources/security/ltpa.keys
USER 1001
```
Please note that this pattern will duplicate the docker layers for those artifacts, which can heavily bloat your resulting docker image (depending on the size of the artifact). So it is recommended to set the permissions before or during copy.
## Tags
There are multiple tags available in this repository.
The `kernel-slim` image contains just the Liberty kernel and no additional runtime features. This image is the recommended basis for custom built images, so that they can contain only the features required for a specific application. For example, the following Dockerfile starts with this image, copies in the `server.xml` that lists the features required by the application, and then uses the `features.sh` script to download those features from the online repository.
```dockerfile
FROM open-liberty:kernel-slim
# Add server configuration
COPY --chown=1001:0 server.xml /config/
# This script will add the requested XML snippets to enable Liberty features and grow image to be fit-for-purpose using featureUtility.
# Only available in 'kernel-slim'. The 'full' tag already includes all features for convenience.
RUN features.sh
# Add the application
COPY --chown=1001:0 Sample1.war /config/dropins/
# This script will add the requested server configurations, apply any interim fixes and populate caches to optimize runtime.
RUN configure.sh
```
The full list of images are found in the `Supported tags and respective Dockerfile links` section above.
# Usage
The images are designed to support a number of different usage patterns. The following examples are based on the Java EE8 Liberty [application deployment sample](https://developer.ibm.com/wasdev/docs/article_appdeployment/) and assume that [DefaultServletEngine.zip](https://github.com/WASdev/sample.servlet/releases/download/V1/DefaultServletEngine.zip) has been extracted to `/tmp` and the `server.xml` updated to accept HTTP connections from outside of the container by adding the following element inside the `server` stanza (if not using one of the pre-packaged `server.xml` files with our tags):
```xml
<httpEndpoint host="*" httpPort="9080" httpsPort="-1"/>
```
## Application Image
It is a very strong best practice to create an extending Docker image, we called it the `application image`, that encapsulates an application and its configuration. This creates a robust, self-contained and predictable Docker image that can span new containers upon request, without relying on volumes or other external runtime artifacts that may behave different over time.
If you want to build the smallest possible Open Liberty application image you can start with our `kernel` tag, add your artifacts, and run `configure.sh` to grow the set of features to be fit-for-purpose. Please see our [GitHub page](https://github.com/OpenLiberty/ci.docker#building-an-application-image) for more details.
## Enabling Enterprise functionality
The Open Liberty images have a set of built-in XML snippets that enable and configure enterprise functionality such as session cache and monitoring. These are toggled by specific `ARG`s in your application image Dockerfile and configured via the `configure.sh` script. Please see the [instructions](https://github.com/openliberty/ci.docker#enterprise-functionality) on our GitHub page for more information.
## Using volumes for configuration
This pattern can be useful for quick experiments / early development (i.e. `I just want to run the application as I iterate over it`), but should not be used for development scenarios that involve different teams and environments - for these cases the `Application Image` pattern described above is the way to go.
When using `volumes`, an application file can be mounted in the `dropins` directory of this server and run. The following example starts a container in the background running a .WAR file from the host file system with the HTTP and HTTPS ports mapped to 80 and 443 respectively.
```console
$ docker run -d -p 80:9080 -p 443:9443 \
-v /tmp/DefaultServletEngine/dropins/Sample1.war:/config/dropins/Sample1.war \
open-liberty:full
```
When the server is started, you can browse to http://localhost/Sample1/SimpleServlet on the Docker host.
Note: If you are using the boot2docker virtual machine on OS X or Windows, you need to get the IP of the virtual host by using the command `boot2docker ip` instead of by using localhost.
For greater flexibility over configuration, it is possible to mount an entire server configuration directory from the host and then specify the server name as a parameter to the run command. Note: This particular example server configuration provides only HTTP access.
```console
$ docker run -d -p 80:9080 \
-v /tmp/DefaultServletEngine:/config \
open-liberty:full
```
# Using Spring Boot with Open Liberty
The `full` images introduce capabilities specific to the support of all Liberty features, including Spring Boot applications. This image thus includes the `springBootUtility` used to separate Spring Boot applications into thin applications and dependency library caches. To get these same capabilities without including features you are not using, build instead on top of `kernel` images and run configure.sh for your server.xml, ensuring that it enables either the `springBoot-1.5` or `springBoot-2.0` feature.
To elaborate these capabilities this section assumes the standalone Spring Boot 2.0.x application `hellospringboot.jar` exists in the `/tmp` directory.
1. A Spring Boot application JAR deploys to the `dropins/spring` directory within the default server configuration, not the `dropins` directory. Liberty allows one Spring Boot application per server configuration. You can create a Spring Boot application layer over this image by adding the application JAR to the `dropins/spring` directory. In this example we copied `hellospringboot.jar` from `/tmp` to the same directory containing the following Dockerfile.
```dockerfile
FROM open-liberty:kernel
COPY --chown=1001:0 hellospringboot.jar /config/dropins/spring/
COPY --chown=1001:0 server.xml /config/
RUN configure.sh
```
The custom image can be built and run as follows.
```console
$ docker build -t app .
$ docker run -d -p 8080:9080 app
```
2. The `full` images provide the library cache directory, `lib.index.cache`, which contains an indexed library cache created by the `springBootUtility` command. Use `lib.index.cache` to provide the library cache for a thin application.
You can use the `springBootUtility` command to create thin application and library cache layers over a `full` image. The following example uses docker staging to efficiently build an image that deploys a fat Spring Boot application as two layers containing a thin application and a library cache.
```dockerfile
FROM open-liberty:kernel as staging
COPY --chown=1001:0 hellospringboot.jar /staging/myFatApp.jar
COPY --chown=1001:0 server.xml /config/
RUN springBootUtility thin \
--sourceAppPath=/staging/myFatApp.jar \
--targetThinAppPath=/staging/myThinApp.jar \
--targetLibCachePath=/staging/lib.index.cache
FROM open-liberty:kernel
COPY --chown=1001:0 server.xml /config
COPY --from=staging /staging/lib.index.cache /lib.index.cache
COPY --from=staging /staging/myThinApp.jar /config/dropins/spring/myThinApp.jar
RUN configure.sh
```
For Spring Boot applications packaged with library dependencies that rarely change across continuous application updates, you can use the capabilities mentioned above to to share library caches across containers and to create even more efficient docker layers that leverage the docker build cache.
# Providing your own keystore/truststore
When an `open-liberty` image starts, it can generate a Liberty server XML snippet in `/config/configDropins/defaults/keystore.xml` that specifies a `keyStore` stanza with a generated password. This causes Open Liberty to generate a default keystore and truststore with a self-signed certificate when it starts. Images can request this by setting:
```console
ENV KEYSTORE_REQUIRED "true"
```
When providing your own keystore/truststore, this default behavior can be disabled by adding:
```console
ENV KEYSTORE_REQUIRED "false"
```
It is good practice to place the keystore customization in `/config/configDropins/defaults/keystore.xml` even when not generated since this makes it easier to find and makes moving to the websphere-liberty docker image simpler.
# Using IBM JRE Class data sharing
The IBM JRE provides a feature [Class data sharing](http://www-01.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.lnx.80.doc/diag/understanding/shared_classes.html) which offers transparent and dynamic sharing of data between multiple Java Virtual Machines running on the same host by using shared memory backed by a file. When running the Liberty Docker image, it looks for the file at `/opt/ol/wlp//output/.classCache`. To benefit from Class data sharing, this location needs to be shared between containers either through the host or a data volume container.
Taking the application image from example 3 above, containers can share the host file location (containing the shared cache) `/tmp/open-liberty/classCache` as follows:
```console
docker run -d -p 80:9080 -p 443:9443 \
-v /tmp/open-liberty/classCache:/opt/ol/wlp/output/.classCache app
```
Or, create a named data volume container that exposes a volume at the location of the shared file:
```console
docker run -v /opt/ol/wlp//output/.classCache \
--name classcache open-liberty true
```
Then, run the Open Liberty image with the volumes from the data volume container classcache mounted as follows:
```console
docker run -d -p 80:9080 -p 443:9443 --volumes-from classcache app
```
# Running Open Liberty in read-only mode
Liberty writes to two different directories when running: `/opt/ol/wlp//output` and `/logs`. In order to run the Liberty image in read-only mode these may be mounted as temporary file systems. If using the provided image, the keystore will be generated on initial start up in the server configuration. This means that the server configuration directory either needs to be read-write or the keystore will need to be built into the image. In the example command `/config` is mounted as a read-write volume.
```console
docker run -d -p 80:9080 -p 443:9443 \
--tmpfs /opt/ol/wlp//output --tmpfs /logs -v /config --read-only \
open-liberty:webProfile8
```
# Relationship between Open Liberty and WebSphere Liberty
WebSphere Liberty is a commercial distribution of Open Liberty. There is an official docker image for websphere-liberty. The websphere-liberty docker image predates the open-liberty one, so to make it simpler to move from open-liberty to websphere-liberty (or vice versa) the images are broadly compatible. It should be possible to move from one to the other with a simple FROM clause change. Some considerations for moving between them:
- Open Liberty installs into `/opt/ol` rather than `/opt/ibm`.
- Use the `/config` folder for accessing the server configuration.
- Use the `/output` folder for accessing the server output.
- When adding your own SSL configuration use the `/config/configDropins/defaults/keystore.xml`.
# Image Variants
The `open-liberty` images come in many flavors, each designed for a specific use case.
## `open-liberty:<version>`
This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
## `open-liberty:<version>-slim`
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `open-liberty`. Unless you are working in an environment where *only* the `open-liberty` image will be deployed and you have space constraints, we highly recommend using the default image of this repository.
# License
View [license information](https://github.com/OpenLiberty/open-liberty/blob/master/LICENSE) for the software contained in this image.
As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).
Some additional license information which was able to be auto-detected might be found in [the `repo-info` repository's `open-liberty/` directory](https://github.com/docker-library/repo-info/tree/master/repos/open-liberty).
As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.
```