This is page 23 of 25. Use http://codebase.md/id/docs/get_started/create/basic_markup.html?lines=true&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
--------------------------------------------------------------------------------
/websphere-liberty/content.md:
--------------------------------------------------------------------------------
```markdown
1 | # Overview
2 |
3 | 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/).
4 |
5 | For more information on these images please see our [GitHub repository](https://github.com/WASdev/ci.docker#container-images).
6 |
7 | # Image User
8 |
9 | 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.
10 |
11 | ## Updating folder permissions
12 |
13 | 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:
14 |
15 | ```dockerfile
16 | USER root
17 | RUN mkdir -p /myFolder && chown -R 1001:0 /myFolder
18 | USER 1001
19 | ```
20 |
21 | ## Updating file permissions
22 |
23 | 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.
24 |
25 | You have a few options for doing this: before copying the file, during copy, or after copy.
26 |
27 | ### Updating permissions before copying
28 |
29 | 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`.
30 |
31 | ### Updating permissions during copy
32 |
33 | 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.
34 |
35 | ### Updating permissions after copy
36 |
37 | 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:
38 |
39 | ```dockerfile
40 | USER root
41 | RUN chown 1001:0 /config/jvm.options
42 | RUN chown 1001:0 /output/resources/security/ltpa.keys
43 | USER 1001
44 | ```
45 |
46 | 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.
47 |
48 | # Tags
49 |
50 | 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.
51 |
52 | 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.
53 |
54 | ```dockerfile
55 | FROM %%IMAGE%%:kernel
56 | COPY --chown=1001:0 Sample1.war /config/dropins/
57 | COPY --chown=1001:0 server.xml /config/
58 | RUN configure.sh
59 | ```
60 |
61 | # Usage
62 |
63 | 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):
64 |
65 | ```xml
66 | <httpEndpoint host="*" httpPort="9080" httpsPort="-1"/>
67 | ```
68 |
69 | ## Application Image
70 |
71 | 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.
72 |
73 | 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.
74 |
75 | ## Enabling Enterprise functionality
76 |
77 | 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.
78 |
79 | ## Using volumes for configuration
80 |
81 | 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.
82 |
83 | 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.
84 |
85 | ```console
86 | $ docker run -d -p 80:9080 -p 443:9443 \
87 | -v /tmp/DefaultServletEngine/dropins/Sample1.war:/config/dropins/Sample1.war \
88 | %%IMAGE%%:webProfile8
89 | ```
90 |
91 | When the server is started, you can browse to http://localhost/Sample1/SimpleServlet on the Docker host.
92 |
93 | 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.
94 |
95 | 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.
96 |
97 | ```console
98 | $ docker run -d -p 80:9080 \
99 | -v /tmp/DefaultServletEngine:/config \
100 | %%IMAGE%%:webProfile8
101 | ```
102 |
103 | # Using Spring Boot with WebSphere Liberty
104 |
105 | 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.
106 |
107 | To elaborate these capabilities this section assumes the standalone Spring Boot 2.0.x application `hellospringboot.jar` exists in the `/tmp` directory.
108 |
109 | 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.
110 |
111 | ```dockerfile
112 | FROM %%IMAGE%%:kernel
113 |
114 | COPY --chown=1001:0 hellospringboot.jar /config/dropins/spring/
115 | COPY --chown=1001:0 server.xml /config/
116 |
117 | RUN configure.sh
118 | ```
119 |
120 | The custom image can be built and run as follows.
121 |
122 | ```console
123 | $ docker build -t app .
124 | $ docker run -d -p 8080:9080 app
125 | ```
126 |
127 | 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.
128 |
129 | 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.
130 |
131 | ```dockerfile
132 | FROM %%IMAGE%%:kernel as staging
133 | COPY --chown=1001:0 hellospringboot.jar /staging/myFatApp.jar
134 | COPY --chown=1001:0 server.xml /config/
135 | RUN springBootUtility thin \
136 | --sourceAppPath=/staging/myFatApp.jar \
137 | --targetThinAppPath=/staging/myThinApp.jar \
138 | --targetLibCachePath=/staging/lib.index.cache
139 | FROM %%IMAGE%%:kernel
140 | COPY --chown=1001:0 server.xml /config
141 | COPY --from=staging /staging/lib.index.cache /lib.index.cache
142 | COPY --from=staging /staging/myThinApp.jar /config/dropins/spring/myThinApp.jar
143 | RUN configure.sh
144 | ```
145 |
146 | 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.
147 |
148 | # Providing your own keystore/truststore
149 |
150 | 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.
151 |
152 | # Using IBM JRE Class data sharing
153 |
154 | 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.
155 |
156 | 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:
157 |
158 | ```console
159 | docker run -d -p 80:9080 -p 443:9443 \
160 | -v /tmp/websphere-liberty/classCache:/opt/ibm/wlp/output/.classCache app
161 | ```
162 |
163 | Or, create a named data volume container that exposes a volume at the location of the shared file:
164 |
165 | ```console
166 | docker run -e LICENSE=accept -v /opt/ibm/wlp/output/.classCache \
167 | --name classcache %%IMAGE%% true
168 | ```
169 |
170 | Then, run the WebSphere Liberty image with the volumes from the data volume container classcache mounted as follows:
171 |
172 | ```console
173 | docker run -d -p 80:9080 -p 443:9443 --volumes-from classcache app
174 | ```
175 |
176 | # Running WebSphere Liberty in read-only mode
177 |
178 | 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.
179 |
180 | ```console
181 | docker run -d -p 80:9080 -p 443:9443 \
182 | --tmpfs /opt/ibm/wlp/output --tmpfs /logs -v /config --read-only \
183 | %%IMAGE%%:javaee8
184 | ```
185 |
186 | # Changing locale
187 |
188 | 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 `%%IMAGE%%:full` image, installs the Portuguese language pack, and sets Brazilian Portuguese as the default locale:
189 |
190 | ```dockerfile
191 | FROM %%IMAGE%%:full
192 | RUN apt-get update \
193 | && apt-get install -y language-pack-pt-base \
194 | && rm -rf /var/lib/apt/lists/*
195 | ENV LANG pt_BR.UTF-8
196 | ```
197 |
```
--------------------------------------------------------------------------------
/bonita/content.md:
--------------------------------------------------------------------------------
```markdown
1 | # What is Bonita?
2 |
3 | Bonita is an open-source business process management and workflow suite created in 2001. It was started in France National Institute for Research in Computer Science, and then had incubated several years inside the French computer science company Groupe Bull. Since 2009, the development of Bonita is supported by a company dedicated to this activity: Bonitasoft.
4 |
5 | > [wikipedia.org/wiki/Bonita_BPM](http://en.wikipedia.org/wiki/Bonita_BPM)
6 |
7 | %%LOGO%%
8 |
9 | # How to use this image
10 |
11 | ## Quick start
12 |
13 | ```console
14 | $ docker run --name bonita -d -p 8080:8080 %%IMAGE%%
15 | ```
16 |
17 | This will start a container running [Bonita runtime](https://documentation.bonitasoft.com/bonita/latest/tomcat-bundle): a Tomcat bundle with Bonita Engine + Bonita Portal. With no environment variables specified, it's as if you have launched the bundle on your host using startup.{sh|bat} (with security hardening on REST and HTTP APIs, cf Security part). Bonita uses a H2 database here.
18 |
19 | You can access the Bonita Portal on http://localhost:8080/bonita and login using the default credentials: install / install
20 |
21 | ## Link Bonita to a database
22 |
23 | The H2 database allows the Bonita container to work out of the box, but it is not recommended outside a development environment.
24 |
25 | As PostgreSQL is the recommended database for qualification and production environments, follow one of these next sections to configure your Bonita container to run on PostgreSQL database. You can work with either a PostgreSQL Container, or PostgreSQL as an installed service.
26 |
27 | ### PostgreSQL Container
28 |
29 | From Bonita 2022.1 onwards, the Bonita docker image does not include configuration scripts to automatically create databases and users anymore.
30 |
31 | Therefore the PostgreSQL container needs to be configured to work with Bonita before starting the Bonita container. The configuration of a PostgreSQL database to work with Bonita is described in details in the [database configuration page](https://documentation.bonitasoft.com/bonita/latest/runtime/database-configuration#postgres_setup). + Alternatively, Bonita provides a preconfigured [PostgreSQL image](https://hub.docker.com/r/bonitasoft/bonita-postgres) on docker-hub. + You can run the image with the following command:
32 |
33 | ```bash
34 | docker run --name mydbpostgres -h <hostname> -d bonitasoft/bonita-postgres:16.4
35 | ```
36 |
37 | This image is built from the following [GitHub repository](https://github.com/Bonitasoft-Community/bonita-database-docker/tree/main/postgres/16), which can be further adapted/customized to suit your needs.
38 |
39 | ## %%COMPOSE%%
40 |
41 | Run `docker compose up`, wait for it to initialize completely, and visit `http://localhost:8080` or `http://host-ip:8080` (as appropriate).
42 |
43 | - Replace `<hostname>` with the one used in the licence generation command
44 | - leave double `$$` untouched
45 |
46 | ### PostgreSQL as an installed service
47 |
48 | If you don't want to run your database in a docker container, the following `env.txt` file needs to be configured and provided to the docker run command:
49 |
50 | ```properties
51 | DB_VENDOR=postgres
52 | DB_HOST=172.17.0.2
53 | DB_PORT=5432
54 | DB_NAME=custombonitadb
55 | DB_USER=custombonitauser
56 | DB_PASS=custombonitapass
57 | BIZ_DB_NAME=custombusinessdb
58 | BIZ_DB_USER=custombusinessuser
59 | BIZ_DB_PASS=custombusinesspass
60 | ```
61 |
62 | ```bash
63 | docker run --name=bonita -h <hostname> --env-file=env.txt -d -p 8080:8080 %%IMAGE%%
64 | ```
65 |
66 | ## Start Bonita with custom security credentials
67 |
68 | ```bash
69 | docker run --name=bonita -h <hostname> -e "BONITA_RUNTIME_ADMIN_USERNAME=tech_user" -e "BONITA_RUNTIME_ADMIN_PASSWORD=secret" -e "PLATFORM_LOGIN=pfadmin" -e "PLATFORM_PASSWORD=pfsecret" -d -p 8080:8080 %%IMAGE%%
70 | ```
71 |
72 | Now you can access the Bonita Runtime on localhost:8080/bonita and login using: tech_user / secret
73 |
74 | ## Where data are stored
75 |
76 | Bonita uses tomcat that writes file to a working directory and a temp directory.
77 |
78 | It can be a good practice to mount the following folders into volumes
79 |
80 | - `/opt/bonita/server/temp`
81 | - `/opt/bonita/server/work`
82 |
83 | ## Environment variables
84 |
85 | When you start the bonita image, you can adjust the configuration of the Bonita instance by passing one or more environment variables on the docker run command line.
86 |
87 | ### PLATFORM_LOGIN
88 |
89 | This optional environment variable is used in conjunction with PLATFORM_PASSWORD to define the username for the platform administrator. If it is not specified, the default username `platformAdmin` will be used.
90 |
91 | ### PLATFORM_PASSWORD
92 |
93 | This environment variable is recommended for you to use the Bonita image. It sets the platform administrator password for Bonita. If it is not specified, the default password `platform` will be used.
94 |
95 | ### BONITA_RUNTIME_ADMIN_USERNAME
96 |
97 | This optional environment variable is used in conjunction with BONITA_RUNTIME_ADMIN_PASSWORD to define the username for the tenant administrator. If it is not specified, the default username `install` will be used.
98 |
99 | ### BONITA_RUNTIME_ADMIN_PASSWORD
100 |
101 | This environment variable is recommended for you to use the Bonita image. It sets the tenant administrator password for Bonita. If it is not specified, the default password `install` will be used.
102 |
103 | ### MONITORING_USERNAME
104 |
105 | This optional environment variable is used in conjunction with `MONITORING_PASSWORD` to define the access to endpoints protected with [BASIC Auth access](https://en.wikipedia.org/wiki/Basic_access_authentication): it is used for the JMX remote access. If it is not specified, the default monitoring username `monitoring` will be used.
106 |
107 | ### MONITORING_PASSWORD
108 |
109 | This optional environment variable is used in conjunction with `MONITORING_USERNAME` to define the access to endpoints protected with [BASIC Auth access](https://en.wikipedia.org/wiki/Basic_access_authentication): it is used for the JMX remote access. If it is not specified, the default monitoring password `mon1tor1ng_adm1n` will be used.
110 |
111 | ### HTTP_API
112 |
113 | This optional environment variable is used to enable/disable the Bonita HTTP API. The default value is false, which will deactivate the HTTP API. From Bonita 2022.1, HTTP API is protected with [Basic access authentication](https://en.wikipedia.org/wiki/Basic_access_authentication). See the following 2 parameters to configure Basic access authentication.
114 |
115 | ### HTTP_API_USERNAME
116 |
117 | This optional environment variable is used to configure the HTTP API Basic access authentication username. The default value is `http-api`.
118 |
119 | ### HTTP_API_PASSWORD
120 |
121 | This optional environment variable is used to configure the HTTP API Basic access authentication password. There is no default value, and providing a value is mandatory if `HTTP_API=true`.
122 |
123 | ### JMX_REMOTE_ACCESS
124 |
125 | This optional environment variable is used to enable/disable the access to the [JMX console](https://docs.oracle.com/en/java/javase/11/management/using-jconsole.html) from a remote machine. + Default value is `false`. + The host to connect to is the name / IP address of the bonita server, the port to connect to is 9000. + The credentials to connect are the environment variables [MONITORING_USERNAME](#MONITORING_USERNAME), [MONITORING_PASSWORD](#MONITORING_PASSWORD).
126 |
127 | ### REMOTE_IP_VALVE_ENABLED
128 |
129 | This optional environment variable allows to activate/deactivate [reverse proxy redirection](https://documentation.bonitasoft.com/bonita/latest/runtime/reverse-proxy-configuration). Default value is `false`.
130 |
131 | ### ACCESSLOGS_STDOUT_ENABLED
132 |
133 | This optional environment variable allows to activate/deactivate writing Tomcat access logs to standard output. Default value is `false`.
134 |
135 | ### ACCESSLOGS_FILES_ENABLED
136 |
137 | This optional environment variable allows to activate/deactivate writing Tomcat access logs to a specific file. When activated, will write those logs to `/opt/bonita/logs/` *inside* the docker container. In practice, it is only useful when mounting a volume to the aforementioned directory. Default value is `false`.
138 |
139 | ### ACCESSLOGS_PATH
140 |
141 | If `ACCESSLOGS_FILES_ENABLED=true`, this optional environment variable overrides the default path to the access log files. Default value is `/opt/bonita/logs`.
142 |
143 | ### ACCESSLOGS_PATH_APPEND_HOSTNAME
144 |
145 | If `ACCESSLOGS_FILES_ENABLED=true`, this optional environment variable allows to append a subdirectory with the *hostname* to the full path of the directory to put access log files into. Default value is `false`.
146 |
147 | ### ACCESSLOGS_MAX_DAYS
148 |
149 | If `ACCESSLOGS_FILES_ENABLED=true`, this optional environment variable allows to automatically delete access log files after a certain number of days. Default value is `30`.
150 |
151 | ### HTTP_MAX_THREADS
152 |
153 | This optional environment variable allows to specify the maximum Http thread number Tomcat will use to serve HTTP/1.1 requests. Directly modifies the *maxThreads* parameter in the *server.xml* file of the Tomcat inside the docker container. More information on the usefulness of this parameter can be found [here](https://tomcat.apache.org/tomcat-9.0-doc/config/http.html). Default value is `20`.
154 |
155 | ### JAVA_OPTS
156 |
157 | This optional environment variable is used to customize JAVA_OPTS. The default value is -Xms1024m -Xmx1024m -XX:MaxPermSize=256m. The syntax to use is `-e JAVA_OPTS="-Xms2048m -Xmx2048m -XX:MaxPermSize=1024m"`
158 |
159 | ### DB_VENDOR
160 |
161 | This environment variable is automatically set to postgres or mysql if the Bonita container is linked to a PostgreSQL or MySQL database using --link. The default value is h2. It can be overridden if you don't use the --link capability.
162 |
163 | ### DB_HOST, DB_PORT
164 |
165 | These variables are optional, used in conjunction to configure the bonita image to reach the database instance. There are automatically set if --link is used to run the container.
166 |
167 | ### DB_NAME, DB_USER, DB_PASS
168 |
169 | These variables are used in conjunction to define how Bonita should access its database for internal functioning.
170 |
171 | `DB_NAME` default value is bonitadb.
172 |
173 | `DB_USER` default value is bonitauser.
174 |
175 | `DB_PASS` default value is bonitapass.
176 |
177 | ### BIZ_DB_NAME, BIZ_DB_USER, BIZ_DB_PASS
178 |
179 | These variables are used in conjunction to define how Bonita should access the [Business Data](https://documentation.bonitasoft.com/bonita/latest/data/define-and-deploy-the-bdm) database.
180 |
181 | `BIZ_DB_NAME` default value is businessdb.
182 |
183 | `BIZ_DB_USER` default value is businessuser.
184 |
185 | `BIZ_DB_PASS` default value is businesspass.
186 |
187 | ## Logger configuration
188 |
189 | **Since 2022.1**
190 |
191 | The logger can be configured by mounting a volume on folder `/opt/bonita/conf/logs` containing the configuration files.
192 |
193 | the volume must contain the 2 files [log4j2-loggers.xml](https://raw.githubusercontent.com/bonitasoft/bonita-distrib/10.2.0/tomcat-resources/tomcat-distrib-for-bonita/src/main/resources/tomcat/server/conf/log4j2-loggers.xml) and [log4j2-appenders.xml](https://raw.githubusercontent.com/bonitasoft/bonita-distrib/10.2.0/docker/files/log4j2/log4j2-appenders.xml)
194 |
195 | Any change made to one of this 2 files is automatically hot-reloaded and taken into account immediately.
196 |
197 | ## Security
198 |
199 | This Docker image activates both static and dynamic authorization checks by default on REST API. To be consistent, it also deactivates the HTTP API.
200 |
201 | - REST API authorization
202 |
203 | - [Static authorization checking](https://documentation.bonitasoft.com/bonita/latest/rest-api-authorization#static_authorization)
204 |
205 | - [HTTP API](https://documentation.bonitasoft.com/bonita/latest/rest-api-authorization#_activating_and_deactivating_authorization)
206 |
207 | For specific needs you can override this behavior by setting HTTP_API to true:
208 |
209 | ```console
210 | $ docker run -e HTTP_API=true -e HTTP_API_PASSWORD="My-Cust0m_S3cR3T" --name bonita -d -p 8080:8080 %%IMAGE%%
211 | ```
212 |
213 | ## Update from an earlier version of Bonita
214 |
215 | For updating from a version before 7.10.0, please refer to the [documentation](https://documentation.bonitasoft.com/bonita/latest/version-update/update-with-migration-tool)
216 |
217 | - Stop the container to perform a database backup
218 |
219 | ```console
220 | $ docker stop bonita
221 | ```
222 |
223 | - Retrieve the DB container IP
224 |
225 | ```console
226 | $ docker inspect --format '{{ .NetworkSettings.IPAddress }}' mydbpostgres
227 | 172.17.0.26
228 | ```
229 |
230 | - Dump the database
231 |
232 | ```console
233 | $ export PGPASSWORD=mysecretpassword
234 | $ pg_dump -O -x -h 172.17.0.26 -U postgres bonitadb > /tmp/bonitadb.sql
235 | ```
236 |
237 | Note that businessdb won't be updated by the update tool but you may want to also backup/move it.
238 |
239 | - Load the dump
240 |
241 | ```console
242 | $ export PGPASSWORD=mysecretpassword
243 | $ psql -U postgres -h 172.17.0.26 -d postgres -c "CREATE USER newbonitauser WITH PASSWORD 'newbonitapass';"
244 | $ psql -U postgres -h 172.17.0.26 -d postgres -c "CREATE DATABASE newbonitadb OWNER newbonitauser;"
245 | $ export PGPASSWORD=newbonitapass
246 | $ cat /tmp/bonitadb.sql | psql -U newbonitauser -h 172.17.0.26 newbonitadb
247 | ```
248 |
249 | - Retrieve the last update tool archive from https://www.bonitasoft.com/downloads
250 |
251 | ```console
252 | unzip bonita-update-tool-3.6.0.zip
253 | ```
254 |
255 | - Configure the update tool
256 |
257 | ```console
258 | $ cd bonita-update-tool-3.6.0
259 | ```
260 |
261 | edit the update tool configuration file `Config.properties` to point towards the database.
262 |
263 | ```console
264 | $ vim Config.properties
265 | ```
266 |
267 | For example :
268 |
269 | ```properties
270 | db.vendor=postgres
271 | db.url=jdbc:postgresql://172.17.0.26:5432/newbonitadb
272 | db.driverClass=org.postgresql.Driver
273 | db.user=newbonitauser
274 | db.password=newbonitapass
275 | ```
276 |
277 | - Launch the update tool
278 |
279 | ```console
280 | $ cd bin
281 | $ ./bonita-update-tool
282 | ```
283 |
284 | - Launch the new container pointing towards the copy of the database.
285 |
286 | ```console
287 | $ docker run --name=bonita --link mydbpostgres:postgres -e "DB_NAME=newbonitadb" -e "DB_USER=newbonitauser" -e "DB_PASS=newbonitapass" -d -p 8081:8080 %%IMAGE%%:2024.3-u0
288 | ```
289 |
290 | For more details regarding Bonita update and for version before 7.10.0, see the [documentation](https://documentation.bonitasoft.com/bonita/latest/version-update/migrate-from-an-earlier-version-of-bonita).
291 |
```
--------------------------------------------------------------------------------
/phpmyadmin/content.md:
--------------------------------------------------------------------------------
```markdown
1 | # What is phpMyAdmin?
2 |
3 | phpMyAdmin is a free software tool written in PHP, intended to handle the administration of MySQL over the Web. phpMyAdmin supports a wide range of operations on MySQL and MariaDB. Frequently used operations (managing databases, tables, columns, relations, indexes, users, permissions, etc) can be performed via the user interface, while you still have the ability to directly execute any SQL statement.
4 |
5 | Run phpMyAdmin with Alpine, Apache and PHP FPM.
6 |
7 | %%LOGO%%
8 |
9 | # How to use this image
10 |
11 | All of the following examples will bring you phpMyAdmin on `http://localhost:8080` where you can enjoy your happy MySQL and MariaDB administration.
12 |
13 | ## Credentials
14 |
15 | phpMyAdmin connects using your MySQL server credentials. Please check your corresponding database server image for information on the default username and password or how to specify your own custom credentials during installation.
16 |
17 | The official MySQL and MariaDB images use the following environment variables to define these:
18 |
19 | - `MYSQL_ROOT_PASSWORD` - This variable is mandatory and specifies the password that will be set for the `root` superuser account.
20 | - `MYSQL_USER`, `MYSQL_PASSWORD` - These variables are optional, used in conjunction to create a new user and to set that user's password.
21 |
22 | ## Supported Docker Hub tags
23 |
24 | The following tags are available:
25 |
26 | - `latest`, `fpm`, and `fpm-alpine` are always the most recent released version
27 | - Major versions, such as `5`, `5-fpm`, and `5-fpm-alpine`
28 | - Specific minor versions, such as `5.0`, `5.0-fpm`, and `5-fpm-alpine`
29 | - Specific patch versions, such as `5.0.0`, `5.0.0-fpm`, and `5.0.0-fpm-alpine`. Note that, on rare occasion, there may be an intermediary "docker-only" release, such as 4.9.2-1
30 |
31 | A complete list of tags is [available at Docker Hub](https://hub.docker.com/_/phpmyadmin?tab=tags)
32 |
33 | ## Image variants
34 |
35 | We provide three variations:
36 |
37 | - "apache" includes a full Apache webserver with PHP and includes everything needed to work out of the box. This is the default when only a version number is requested.
38 | - "fpm" only starts a PHP FPM container. Use this variant if you already have a separate webserver. This includes more tools and is therefore a larger image than the "fpm-alpine" variation.
39 | - "fpm-alpine" has a very small footprint. It is based on Alpine Linux and only starts a PHP FPM process. Use this variant if you already have a separate webserver. If you need more tools that are not available on Alpine Linux, use the fpm image instead.
40 |
41 | ## Usage with linked server
42 |
43 | First you need to run a MySQL or MariaDB server in Docker, and the phpMyAdmin image needs to be linked to the running database container:
44 |
45 | ```sh
46 | docker run --name phpmyadmin -d --link mysql_db_server:db -p 8080:80 %%IMAGE%%
47 | ```
48 |
49 | ## Usage with external server
50 |
51 | You can specify a MySQL host in the `PMA_HOST` environment variable. You can also use `PMA_PORT` to specify the port of the server in case it's not the default one:
52 |
53 | ```sh
54 | docker run --name phpmyadmin -d -e PMA_HOST=dbhost -p 8080:80 %%IMAGE%%
55 | ```
56 |
57 | ## Usage with arbitrary server
58 |
59 | You can use arbitrary servers by adding the environment variable `PMA_ARBITRARY=1` to the startup command:
60 |
61 | ```sh
62 | docker run --name phpmyadmin -d -e PMA_ARBITRARY=1 -p 8080:80 %%IMAGE%%
63 | ```
64 |
65 | ## Usage with `docker compose` and an arbitrary server
66 |
67 | This will run phpMyAdmin with the arbitrary server option - allowing you to specify any MySQL/MariaDB server on the login page.
68 |
69 | %%COMPOSE%%
70 |
71 | ## Adding Custom Configuration
72 |
73 | You can add your own custom config.inc.php settings (such as Configuration Storage setup) by creating a file named `config.user.inc.php` with the various user defined settings in it, and then linking it into the container using:
74 |
75 | ```sh
76 | -v /some/local/directory/config.user.inc.php:/etc/phpmyadmin/config.user.inc.php
77 | ```
78 |
79 | On the `docker run` line like this:
80 |
81 | ```sh
82 | docker run --name phpmyadmin -d --link mysql_db_server:db -p 8080:80 -v /some/local/directory/config.user.inc.php:/etc/phpmyadmin/config.user.inc.php %%IMAGE%%
83 | ```
84 |
85 | Be sure to have `<?php` as your first line of the configuration file or the contents will not be detected as PHP code.
86 |
87 | Example:
88 |
89 | ```php
90 | <?php
91 |
92 | $cfg['ShowPhpInfo'] = true; // Adds a link to phpinfo() on the home page
93 | ```
94 |
95 | See the following links for config file information:
96 |
97 | - https://docs.phpmyadmin.net/en/latest/config.html#config
98 | - https://docs.phpmyadmin.net/en/latest/setup.html
99 |
100 | ## Adding custom configuration in `/etc/phpmyadmin/conf.d`
101 |
102 | you can also consider storing your custom configuration files in the folder `/etc/phpmyadmin/conf.d`, which is very suitable for managing multiple phpMyAdmin configuration files for different hosts,Then you can create `server-1.php`, `server-2.php`, or any file name you want, and store them in the conf.d directory mounted on the host.
103 |
104 | On the `docker run` line like this:
105 |
106 | ```sh
107 | docker run --name phpmyadmin -d --link mysql_db_server:db -p 8080:80 -v /some/local/directory/conf.d:/etc/phpmyadmin/conf.d:ro %%IMAGE%%
108 | ```
109 |
110 | ## Usage behind a reverse proxy
111 |
112 | Set the variable `PMA_ABSOLUTE_URI` to the fully-qualified path (`https://pma.example.net/`) where the reverse proxy makes phpMyAdmin available.
113 |
114 | ## Sessions persistence
115 |
116 | In order to keep your sessions active between container updates you will need to mount the `/sessions` folder.
117 |
118 | ```sh
119 | -v /some/local/directory/sessions:/sessions:rw
120 | ```
121 |
122 | ## Connect to the database over SSL
123 |
124 | Set the variable `PMA_SSL` to `1` to enable SSL usage from phpMyAdmin to the MySQL server. The default value is `0`. The variable `PMA_SSLS` can be used as a comma seperated sequence of `0` and `1` where multiple hosts are mentioned. Values order must follow the `PMA_HOSTS` and will be computed accordingly.
125 |
126 | ```sh
127 | docker run --name phpmyadmin -d -e PMA_HOSTS=sslhost -e PMA_SSL=1 -p 8080:80 %%IMAGE%%
128 | ```
129 |
130 | ```sh
131 | docker run --name phpmyadmin -d -e PMA_HOSTS='sslhost,nosslhost' -e PMA_SSLS='1,0' -p 8080:80 %%IMAGE%%
132 | ```
133 |
134 | ## Environment variables summary
135 |
136 | - `PMA_ARBITRARY` - when set to 1 connection to the arbitrary server will be allowed
137 | - `PMA_HOST` - define address/host name of the MySQL server
138 | - `PMA_VERBOSE` - define verbose name of the MySQL server
139 | - `PMA_PORT` - define port of the MySQL server
140 | - `PMA_HOSTS` - define comma separated list of address/host names of the MySQL servers
141 | - `PMA_VERBOSES` - define comma separated list of verbose names of the MySQL servers
142 | - `PMA_PORTS` - define comma separated list of ports of the MySQL servers
143 | - `PMA_SOCKET` - define socket file for the MySQL connection
144 | - `PMA_SOCKETS` - define comma separated list of socket files for the MySQL connections
145 | - `PMA_SSL_DIR` - define the path used for SSL files generated from environement variables, default value is `/etc/phpmyadmin/ssl`
146 | - `PMA_SSL` - when set to 1, defines SSL usage for the MySQL connection
147 | - `PMA_SSLS` - comma separated list of `0` and `1` defining SSL usage for the corresponding MySQL connections
148 | - `PMA_SSL_VERIFY` - when set to 1, enables SSL certificate verification for the MySQL connection.
149 | - `PMA_SSL_VERIFIES` - comma-separated list of `0` and `1` to enable or disable SSL certificate verification for multiple MySQL connections.
150 | - `PMA_SSL_CA` - in the context of mutual TLS security, allows setting your CA certificate file as a string inside the default `config.inc.php`.
151 | - `PMA_SSL_CAS` - in the context of mutual TLS security, allows setting multiple CA certificate files as a comma-separated list of strings inside the default `config.inc.php`.
152 | - `PMA_SSL_CERT` - in the context of mutual TLS security, allows setting your certificate file as a string inside the default `config.inc.php`.
153 | - `PMA_SSL_CERTS` - in the context of mutual TLS security, allows setting multiple certificate files as a comma-separated list of strings inside the default `config.inc.php`.
154 | - `PMA_SSL_KEY` - in the context of mutual TLS security, allows setting your private key file as a string inside the default `config.inc.php`.
155 | - `PMA_SSL_KEYS` - in the context of mutual TLS security, allows setting multiple private key files as a comma-separated list of strings inside the default `config.inc.php`.
156 | - `PMA_USER` and `PMA_PASSWORD` - define username and password to use only with the `config` authentication method
157 | - `PMA_ABSOLUTE_URI` - the full URL to phpMyAdmin. Sometimes needed when used in a reverse-proxy configuration. Don't set this unless needed. See [documentation](https://docs.phpmyadmin.net/en/latest/config.html#cfg_PmaAbsoluteUri).
158 | - `PMA_CONFIG_BASE64` - if set, this option will override the default `config.inc.php` with the base64 decoded contents of the variable
159 | - `PMA_USER_CONFIG_BASE64` - if set, this option will override the default `config.user.inc.php` with the base64 decoded contents of the variable
160 | - `PMA_UPLOADDIR` - if defined, this option will set the path where files can be saved to be available to import ([$cfg['UploadDir']](https://docs.phpmyadmin.net/en/latest/config.html#cfg_UploadDir))
161 | - `PMA_SAVEDIR` - if defined, this option will set the path where exported files can be saved ([$cfg['SaveDir']](https://docs.phpmyadmin.net/en/latest/config.html#cfg_SaveDir))
162 | - `PMA_CONTROLHOST` - when set, this points to an alternate database host used for storing the [phpMyAdmin Configuration Storage database](https://docs.phpmyadmin.net/en/latest/setup.html#phpmyadmin-configuration-storage) database
163 | - `PMA_CONTROLPORT` - if set, will override the default port (3306) for connecting to the control host for storing the [phpMyAdmin Configuration Storage database](https://docs.phpmyadmin.net/en/latest/setup.html#phpmyadmin-configuration-storage) database
164 | - `PMA_PMADB` - define the name of the database to be used for the [phpMyAdmin Configuration Storage database](https://docs.phpmyadmin.net/en/latest/setup.html#phpmyadmin-configuration-storage). When not set, the advanced features are not enabled by default: they can still potentially be enabled by the user when logging in with the zero conf (zero configuration) feature. Suggested values: `phpmyadmin` or `pmadb`
165 | - `PMA_CONTROLUSER` - define the username for phpMyAdmin to use for advanced features (the [controluser](https://docs.phpmyadmin.net/en/latest/config.html#cfg_Servers_controluser))
166 | - `PMA_CONTROLPASS` - define the password for phpMyAdmin to use with the [controluser](https://docs.phpmyadmin.net/en/latest/config.html#cfg_Servers_controlpass)
167 | - `PMA_QUERYHISTORYDB` - when set [to true](https://docs.phpmyadmin.net/en/latest/config.html#cfg_QueryHistoryDB), enables storing [SQL history](https://docs.phpmyadmin.net/en/latest/config.html#cfg_Servers_history) to the [phpMyAdmin Configuration Storage database](https://docs.phpmyadmin.net/en/latest/setup.html#phpmyadmin-configuration-storage). When [false](https://docs.phpmyadmin.net/en/latest/config.html#cfg_QueryHistoryDB), history is stored in the browser and is cleared when logging out
168 | - `PMA_QUERYHISTORYMAX` - when set to an integer, controls the number of history items. See [documentation](https://docs.phpmyadmin.net/en/latest/config.html#cfg_QueryHistoryMax). Defaults to `25`.
169 | - `MAX_EXECUTION_TIME` - if set, will override the maximum execution time in seconds (default 600) for phpMyAdmin ([$cfg['ExecTimeLimit']](https://docs.phpmyadmin.net/en/latest/config.html#cfg_ExecTimeLimit)) and PHP [max_execution_time](https://www.php.net/manual/en/info.configuration.php#ini.max-execution-time) (format as `[0-9+]`)
170 | - `MEMORY_LIMIT` - if set, will override the memory limit (default 512M) for phpMyAdmin ([$cfg['MemoryLimit']](https://docs.phpmyadmin.net/en/latest/config.html#cfg_MemoryLimit)) and PHP [memory_limit](https://www.php.net/manual/en/ini.core.php#ini.memory-limit) (format as `[0-9+](K,M,G)` where K is for Kilobytes, M for Megabytes, G for Gigabytes and 1K = 1024 bytes)
171 | - `UPLOAD_LIMIT` - if set, this option will override the default value for apache and php-fpm (format as `[0-9+](K,M,G)` default value is 2048K, this will change `upload_max_filesize` and `post_max_size` values)
172 | - `TZ` - if defined, this option will change the default PHP `date.timezone` from `UTC`. See [documentation](https://www.php.net/manual/en/timezones.php) for supported values.
173 | - `HIDE_PHP_VERSION` - if defined, this option will hide the PHP version (`expose_php = Off`). Set to any value (such as `HIDE_PHP_VERSION=true`).
174 | - `APACHE_PORT` - if defined, this option will change the default Apache port from `80` in case you want it to run on a different port like an unprivileged port. Set to any port value (such as `APACHE_PORT=8090`)
175 |
176 | For usage with Docker secrets, appending `_FILE` to the `PMA_PASSWORD` environment variable is allowed (it overrides `PMA_PASSWORD` if it is set):
177 |
178 | ```sh
179 | docker run --name phpmyadmin -d -e PMA_PASSWORD_FILE=/run/secrets/db_password.txt -p 8080:80 %%IMAGE%%
180 | ```
181 |
182 | #### Variables that can store the file contents using `_BASE64`
183 |
184 | - `PMA_SSL_CA`
185 | - `PMA_SSL_CAS`
186 | - `PMA_SSL_KEY`
187 | - `PMA_SSL_KEYS`
188 | - `PMA_SSL_CERT`
189 | - `PMA_SSL_CERTS`
190 |
191 | Also includes: `PMA_CONFIG_BASE64` or `PMA_USER_CONFIG_BASE64`.
192 |
193 | For example, the variable would be named `PMA_SSL_CA_BASE64` and the value is the base64 encoded contents of the file.
194 |
195 | #### Variables that can be read from a file using `_FILE`
196 |
197 | - `MYSQL_ROOT_PASSWORD`
198 | - `MYSQL_PASSWORD`
199 | - `PMA_USER`
200 | - `PMA_PASSWORD`
201 | - `PMA_HOSTS`
202 | - `PMA_HOST`
203 | - `PMA_CONTROLHOST`
204 | - `PMA_CONTROLUSER`
205 | - `PMA_CONTROLPASS`
206 |
207 | For more detailed documentation see https://docs.phpmyadmin.net/en/latest/setup.html#installing-using-docker
208 |
209 | Please report any issues with the Docker container to https://github.com/phpmyadmin/docker/issues
210 |
211 | Please report any issues with phpMyAdmin to https://github.com/phpmyadmin/phpmyadmin/issues
212 |
```
--------------------------------------------------------------------------------
/mongo/content.md:
--------------------------------------------------------------------------------
```markdown
1 | # What is MongoDB?
2 |
3 | MongoDB is a [free and open-source cross-platform document-oriented database](https://en.wikipedia.org/wiki/Document-oriented_database) program. Classified as a [NoSQL](https://en.wikipedia.org/wiki/NoSQL) database program, MongoDB uses [JSON](https://en.wikipedia.org/wiki/JSON)-like documents with [schemata](https://en.wikipedia.org/wiki/Database_schema). MongoDB is developed by [MongoDB Inc.](https://en.wikipedia.org/wiki/MongoDB_Inc.), and is published under a combination of the [Server Side Public License](https://www.mongodb.com/licensing/server-side-public-license) and the [Apache License](https://en.wikipedia.org/wiki/Apache_License).
4 |
5 | First developed by the software company 10gen (now MongoDB Inc.) in October 2007 as a component of a planned platform as a service product, the company shifted to an open source development model in 2009, with 10gen offering commercial support and other services. Since then, MongoDB has been adopted as backend software by a number of major websites and services, including MetLife, Barclays, ADP, UPS, Viacom, and the New York Times, among others. MongoDB is the most popular NoSQL database system.
6 |
7 | > [wikipedia.org/wiki/MongoDB](https://en.wikipedia.org/wiki/MongoDB)
8 |
9 | %%LOGO%%
10 |
11 | # Security
12 |
13 | By default Mongo's configuration requires no authentication for access, even for the administrative user. It is highly recommended to set a root user name and password if you plan on exposing your Mongo instance to the internet. See the "`MONGO_INITDB_ROOT_USERNAME`, `MONGO_INITDB_ROOT_PASSWORD`" section below for instructions and the [MongoDB Security documentation](https://www.mongodb.com/docs/manual/security/) for a more complete treatment.
14 |
15 | # How to use this image
16 |
17 | ## Start a `%%REPO%%` server instance
18 |
19 | ```console
20 | $ docker run --name some-%%REPO%% -d %%IMAGE%%:tag
21 | ```
22 |
23 | ... where `some-%%REPO%%` is the name you want to assign to your container and `tag` is the tag specifying the MongoDB version you want. See the list above for relevant tags.
24 |
25 | ## Connect to MongoDB from another Docker container
26 |
27 | The MongoDB server in the image listens on the standard MongoDB port, `27017`, so connecting via Docker networks will be the same as connecting to a remote `mongod`. The following example starts another MongoDB container instance and runs the `mongosh` (use `mongo` with `4.x` versions) command line client against the original MongoDB container from the example above, allowing you to execute MongoDB statements against your database instance:
28 |
29 | ```console
30 | $ docker run -it --network some-network --rm %%IMAGE%% mongosh --host some-%%REPO%% test
31 | ```
32 |
33 | ... where `some-%%REPO%%` is the name of your original `mongo` container.
34 |
35 | ## %%COMPOSE%%
36 |
37 | Run `docker compose up`, wait for it to initialize completely, and visit `http://localhost:8081` or `http://host-ip:8081` (as appropriate).
38 |
39 | ## Container shell access and viewing MongoDB logs
40 |
41 | The `docker exec` command allows you to run commands inside a Docker container. The following command line will give you a bash shell inside your `%%IMAGE%%` container:
42 |
43 | ```console
44 | $ docker exec -it some-%%REPO%% bash
45 | ```
46 |
47 | The MongoDB Server log is available through Docker's container log:
48 |
49 | ```console
50 | $ docker logs some-%%REPO%%
51 | ```
52 |
53 | # Configuration
54 |
55 | See the [MongoDB manual](https://docs.mongodb.com/manual/) for information on using and configuring MongoDB for things like replica sets and sharding.
56 |
57 | ## Customize configuration without configuration file
58 |
59 | Most MongoDB configuration can be set through flags to `mongod`. The entrypoint of the image is created to pass its arguments along to `mongod`. See below an example of setting MongoDB to use a different [threading and execution model](https://docs.mongodb.com/manual/reference/program/mongod/#cmdoption-mongod-serviceexecutor) via `docker run`.
60 |
61 | ```console
62 | $ docker run --name some-%%REPO%% -d %%IMAGE%% --serviceExecutor adaptive
63 | ```
64 |
65 | And here is the same with a `compose.yaml` file
66 |
67 | ```yaml
68 | services:
69 | mongo:
70 | image: %%IMAGE%%
71 | command: --serviceExecutor adaptive
72 | ```
73 |
74 | To see the full list of possible options, check the MongoDB manual on [`mongod`](https://docs.mongodb.com/manual/reference/program/mongod/) or check the `--help` output of `mongod`:
75 |
76 | ```console
77 | $ docker run -it --rm %%IMAGE%% --help
78 | ```
79 |
80 | ## Setting WiredTiger cache size limits
81 |
82 | By default Mongo will set the `wiredTigerCacheSizeGB` to a value proportional to the host's total memory regardless of memory limits you may have imposed on the container. In such an instance you will want to set the cache size to something appropriate, taking into account any other processes you may be running in the container which would also utilize memory.
83 |
84 | Taking the examples above you can configure the cache size to use 1.5GB as:
85 |
86 | ```console
87 | $ docker run --name some-%%REPO%% -d %%IMAGE%% --wiredTigerCacheSizeGB 1.5
88 | ```
89 |
90 | See [the upstream "WiredTiger Options" documentation](https://docs.mongodb.com/manual/reference/program/mongod/#wiredtiger-options) for more details.
91 |
92 | ## Using a custom MongoDB configuration file
93 |
94 | For a more complicated configuration setup, you can still use the MongoDB configuration file. `mongod` does not read a configuration file by default, so the `--config` option with the path to the configuration file needs to be specified. Create a custom configuration file and put it in the container by either creating a custom Dockerfile `FROM %%IMAGE%%` or mounting it from the host machine to the container. See the MongoDB manual for a full list of [configuration file](https://docs.mongodb.com/manual/reference/configuration-options/) options.
95 |
96 | For example, `/my/custom/mongod.conf` is the path to the custom configuration file. Then start the MongoDB container like the following:
97 |
98 | ```console
99 | $ docker run --name some-%%REPO%% -v /my/custom:/etc/mongo -d %%IMAGE%% --config /etc/mongo/mongod.conf
100 | ```
101 |
102 | ## Environment Variables
103 |
104 | When you start the `%%REPO%%` image, you can adjust the initialization of the MongoDB instance by passing one or more environment variables on the `docker run` command line. Do note that none of the variables below will have any effect if you start the container with a data directory that already contains a database: any pre-existing database will always be left untouched on container startup.
105 |
106 | ### `MONGO_INITDB_ROOT_USERNAME`, `MONGO_INITDB_ROOT_PASSWORD`
107 |
108 | These variables, used in conjunction, create a new user and set that user's password. This user is created in the `admin` [authentication database](https://docs.mongodb.com/manual/core/security-users/#user-authentication-database) and given [the role of `root`](https://docs.mongodb.com/manual/reference/built-in-roles/#root), which is [a "superuser" role](https://docs.mongodb.com/manual/core/security-built-in-roles/#superuser-roles).
109 |
110 | The following is an example of using these two variables to create a MongoDB instance and then using the `mongosh` cli (use `mongo` with `4.x` versions) to connect against the `admin` authentication database.
111 |
112 | ```console
113 | $ docker run -d --network some-network --name some-%%REPO%% \
114 | -e MONGO_INITDB_ROOT_USERNAME=mongoadmin \
115 | -e MONGO_INITDB_ROOT_PASSWORD=secret \
116 | %%IMAGE%%
117 |
118 | $ docker run -it --rm --network some-network %%IMAGE%% \
119 | mongosh --host some-mongo \
120 | -u mongoadmin \
121 | -p secret \
122 | --authenticationDatabase admin \
123 | some-db
124 | > db.getName();
125 | some-db
126 | ```
127 |
128 | Both variables are required for a user to be created. If both are present then MongoDB will start with authentication enabled (`mongod --auth`).
129 |
130 | Authentication in MongoDB is fairly complex, so more complex user setup is explicitly left to the user via `/docker-entrypoint-initdb.d/` (see the *Initializing a fresh instance* and *Authentication* sections below for more details).
131 |
132 | ### `MONGO_INITDB_DATABASE`
133 |
134 | This variable allows you to specify the name of a database to be used for creation scripts in `/docker-entrypoint-initdb.d/*.js` (see *Initializing a fresh instance* below). MongoDB is fundamentally designed for "create on first use", so if you do not insert data with your JavaScript files, then no database is created.
135 |
136 | ## Docker Secrets
137 |
138 | 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:
139 |
140 | ```console
141 | $ docker run --name some-%%REPO%% -e MONGO_INITDB_ROOT_PASSWORD_FILE=/run/secrets/mongo-root -d %%IMAGE%%
142 | ```
143 |
144 | Currently, this is only supported for `MONGO_INITDB_ROOT_USERNAME` and `MONGO_INITDB_ROOT_PASSWORD`.
145 |
146 | # Initializing a fresh instance
147 |
148 | When a container is started for the first time it will execute files with extensions `.sh` and `.js` that are found in `/docker-entrypoint-initdb.d`. Files will be executed in alphabetical order. `.js` files will be executed by `mongosh` (`mongo` on versions below 6) using the database specified by the `MONGO_INITDB_DATABASE` variable, if it is present, or `test` otherwise. You may also switch databases within the `.js` script.
149 |
150 | # Authentication
151 |
152 | As noted above, authentication in MongoDB is fairly complex (although disabled by default). For details about how MongoDB handles authentication, please see the relevant upstream documentation:
153 |
154 | - [`mongod --auth`](https://docs.mongodb.com/manual/reference/program/mongod/#cmdoption-mongod-auth)
155 | - [Security > Authentication](https://docs.mongodb.com/manual/core/authentication/)
156 | - [Security > Role-Based Access Control](https://docs.mongodb.com/manual/core/authorization/)
157 | - [Security > Role-Based Access Control > Built-In Roles](https://docs.mongodb.com/manual/core/security-built-in-roles/)
158 | - [Security > Enable Auth (tutorial)](https://docs.mongodb.com/manual/tutorial/enable-authentication/)
159 |
160 | In addition to the `/docker-entrypoint-initdb.d` behavior documented above (which is a simple way to configure users for authentication for less complicated deployments), this image also supports `MONGO_INITDB_ROOT_USERNAME` and `MONGO_INITDB_ROOT_PASSWORD` for creating a simple user with [the role `root`](https://docs.mongodb.com/manual/reference/built-in-roles/#root) in the `admin` [authentication database](https://docs.mongodb.com/manual/core/security-users/#user-authentication-database), as described in the *Environment Variables* section above.
161 |
162 | # Caveats
163 |
164 | ## Where to Store Data
165 |
166 | Important note: There are several ways to store data used by applications that run in Docker containers. We encourage users of the `%%REPO%%` images to familiarize themselves with the options available, including:
167 |
168 | - Let Docker 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.
169 | - 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.
170 |
171 | **WARNING (Windows & OS X)**: When running the Linux-based MongoDB images on Windows and OS X, the file systems used to share between the host system and the Docker container is not compatible with the memory mapped files used by MongoDB ([docs.mongodb.org](https://docs.mongodb.com/manual/administration/production-notes/#fsync---on-directories) and related [jira.mongodb.org](https://jira.mongodb.org/browse/SERVER-8600) bug). This means that it is not possible to run a MongoDB container with the data directory mapped to the host. To persist data between container restarts, we recommend using a local named volume instead (see `docker volume create`). Alternatively you can use the Windows-based images on Windows.
172 |
173 | 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:
174 |
175 | 1. Create a data directory on a suitable volume on your host system, e.g. `/my/own/datadir`.
176 | 2. Start your `%%REPO%%` container like this:
177 |
178 | ```console
179 | $ docker run --name some-%%REPO%% -v /my/own/datadir:/data/db -d %%IMAGE%%
180 | ```
181 |
182 | The `-v /my/own/datadir:/data/db` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/data/db` inside the container, where MongoDB by default will write its data files.
183 |
184 | This image also defines a volume for `/data/configdb` [for use with `--configsvr` (see docs.mongodb.com for more details)](https://docs.mongodb.com/v3.4/reference/program/mongod/#cmdoption-configsvr).
185 |
186 | ## Creating database dumps
187 |
188 | Most of the normal tools will work, although their usage might be a little convoluted in some cases to ensure they have access to the `mongod` server. A simple way to ensure this is to use `docker exec` and run the tool from the same container, similar to the following:
189 |
190 | ```console
191 | $ docker exec some-%%REPO%% sh -c 'exec mongodump -d <database_name> --archive' > /some/path/on/your/host/all-collections.archive
192 | ```
193 |
```
--------------------------------------------------------------------------------
/open-liberty/content.md:
--------------------------------------------------------------------------------
```markdown
1 | # Overview
2 |
3 | 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/).
4 |
5 | For more information on these images please see our [GitHub repository](https://github.com/OpenLiberty/ci.docker#container-images).
6 |
7 | # Image User
8 |
9 | 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.
10 |
11 | ## Updating folder permissions
12 |
13 | 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:
14 |
15 | ```dockerfile
16 | USER root
17 | RUN mkdir -p /myFolder && chown -R 1001:0 /myFolder
18 | USER 1001
19 | ```
20 |
21 | ## Updating file permissions
22 |
23 | 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.
24 |
25 | You have a few options for doing this: before copying the file, during copy, or after copy.
26 |
27 | ### Updating permissions before copying
28 |
29 | 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`.
30 |
31 | ### Updating permissions during copy
32 |
33 | 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.
34 |
35 | ### Updating permissions after copy
36 |
37 | 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:
38 |
39 | ```dockerfile
40 | USER root
41 | RUN chown 1001:0 /config/jvm.options
42 | RUN chown 1001:0 /output/resources/security/ltpa.keys
43 | USER 1001
44 | ```
45 |
46 | 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.
47 |
48 | ## Tags
49 |
50 | There are multiple tags available in this repository.
51 |
52 | 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.
53 |
54 | ```dockerfile
55 | FROM %%IMAGE%%:kernel-slim
56 |
57 | # Add server configuration
58 | COPY --chown=1001:0 server.xml /config/
59 | # This script will add the requested XML snippets to enable Liberty features and grow image to be fit-for-purpose using featureUtility.
60 | # Only available in 'kernel-slim'. The 'full' tag already includes all features for convenience.
61 | RUN features.sh
62 |
63 | # Add the application
64 | COPY --chown=1001:0 Sample1.war /config/dropins/
65 | # This script will add the requested server configurations, apply any interim fixes and populate caches to optimize runtime.
66 | RUN configure.sh
67 | ```
68 |
69 | The full list of images are found in the `Supported tags and respective Dockerfile links` section above.
70 |
71 | # Usage
72 |
73 | 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):
74 |
75 | ```xml
76 | <httpEndpoint host="*" httpPort="9080" httpsPort="-1"/>
77 | ```
78 |
79 | ## Application Image
80 |
81 | 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.
82 |
83 | 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.
84 |
85 | ## Enabling Enterprise functionality
86 |
87 | 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.
88 |
89 | ## Using volumes for configuration
90 |
91 | 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.
92 |
93 | 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.
94 |
95 | ```console
96 | $ docker run -d -p 80:9080 -p 443:9443 \
97 | -v /tmp/DefaultServletEngine/dropins/Sample1.war:/config/dropins/Sample1.war \
98 | %%IMAGE%%:full
99 | ```
100 |
101 | When the server is started, you can browse to http://localhost/Sample1/SimpleServlet on the Docker host.
102 |
103 | 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.
104 |
105 | 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.
106 |
107 | ```console
108 | $ docker run -d -p 80:9080 \
109 | -v /tmp/DefaultServletEngine:/config \
110 | %%IMAGE%%:full
111 | ```
112 |
113 | # Using Spring Boot with Open Liberty
114 |
115 | 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.
116 |
117 | To elaborate these capabilities this section assumes the standalone Spring Boot 2.0.x application `hellospringboot.jar` exists in the `/tmp` directory.
118 |
119 | 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.
120 |
121 | ```dockerfile
122 | FROM %%IMAGE%%:kernel
123 |
124 | COPY --chown=1001:0 hellospringboot.jar /config/dropins/spring/
125 | COPY --chown=1001:0 server.xml /config/
126 |
127 | RUN configure.sh
128 | ```
129 |
130 | The custom image can be built and run as follows.
131 |
132 | ```console
133 | $ docker build -t app .
134 | $ docker run -d -p 8080:9080 app
135 | ```
136 |
137 | 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.
138 |
139 | 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.
140 |
141 | ```dockerfile
142 | FROM %%IMAGE%%:kernel as staging
143 | COPY --chown=1001:0 hellospringboot.jar /staging/myFatApp.jar
144 | COPY --chown=1001:0 server.xml /config/
145 | RUN springBootUtility thin \
146 | --sourceAppPath=/staging/myFatApp.jar \
147 | --targetThinAppPath=/staging/myThinApp.jar \
148 | --targetLibCachePath=/staging/lib.index.cache
149 | FROM %%IMAGE%%:kernel
150 | COPY --chown=1001:0 server.xml /config
151 | COPY --from=staging /staging/lib.index.cache /lib.index.cache
152 | COPY --from=staging /staging/myThinApp.jar /config/dropins/spring/myThinApp.jar
153 | RUN configure.sh
154 | ```
155 |
156 | 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.
157 |
158 | # Providing your own keystore/truststore
159 |
160 | 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:
161 |
162 | ```console
163 | ENV KEYSTORE_REQUIRED "true"
164 | ```
165 |
166 | When providing your own keystore/truststore, this default behavior can be disabled by adding:
167 |
168 | ```console
169 | ENV KEYSTORE_REQUIRED "false"
170 | ```
171 |
172 | 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.
173 |
174 | # Using IBM JRE Class data sharing
175 |
176 | 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.
177 |
178 | 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:
179 |
180 | ```console
181 | docker run -d -p 80:9080 -p 443:9443 \
182 | -v /tmp/open-liberty/classCache:/opt/ol/wlp/output/.classCache app
183 | ```
184 |
185 | Or, create a named data volume container that exposes a volume at the location of the shared file:
186 |
187 | ```console
188 | docker run -v /opt/ol/wlp//output/.classCache \
189 | --name classcache %%IMAGE%% true
190 | ```
191 |
192 | Then, run the Open Liberty image with the volumes from the data volume container classcache mounted as follows:
193 |
194 | ```console
195 | docker run -d -p 80:9080 -p 443:9443 --volumes-from classcache app
196 | ```
197 |
198 | # Running Open Liberty in read-only mode
199 |
200 | 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.
201 |
202 | ```console
203 | docker run -d -p 80:9080 -p 443:9443 \
204 | --tmpfs /opt/ol/wlp//output --tmpfs /logs -v /config --read-only \
205 | %%IMAGE%%:webProfile8
206 | ```
207 |
208 | # Relationship between Open Liberty and WebSphere Liberty
209 |
210 | 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:
211 |
212 | - Open Liberty installs into `/opt/ol` rather than `/opt/ibm`.
213 | - Use the `/config` folder for accessing the server configuration.
214 | - Use the `/output` folder for accessing the server output.
215 | - When adding your own SSL configuration use the `/config/configDropins/defaults/keystore.xml`.
216 |
```
--------------------------------------------------------------------------------
/ros/content.md:
--------------------------------------------------------------------------------
```markdown
1 | # What is [ROS](https://www.ros.org/)?
2 |
3 | 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.
4 |
5 | > [wikipedia.org/wiki/Robot_Operating_System](https://en.wikipedia.org/wiki/Robot_Operating_System)
6 |
7 | [%%LOGO%%](https://www.ros.org/)
8 |
9 | # How to use this image
10 |
11 | ## Creating a `Dockerfile` to install ROS packages
12 |
13 | 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.
14 |
15 | ```dockerfile
16 | FROM %%IMAGE%%:foxy
17 |
18 | # install ros package
19 | RUN apt-get update && apt-get install -y \
20 | ros-${ROS_DISTRO}-demo-nodes-cpp \
21 | ros-${ROS_DISTRO}-demo-nodes-py && \
22 | rm -rf /var/lib/apt/lists/*
23 |
24 | # launch ros package
25 | CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"]
26 | ```
27 |
28 | 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:
29 |
30 | ```console
31 | $ docker build -t my/ros:app .
32 | $ docker run -it --rm my/ros:app
33 | [INFO] [launch]: process[talker-1]: started with pid [813]
34 | [INFO] [launch]: process[listener-2]: started with pid [814]
35 | [INFO] [talker]: Publishing: 'Hello World: 1'
36 | [INFO] [listener]: I heard: [Hello World: 1]
37 | [INFO] [talker]: Publishing: 'Hello World: 2'
38 | [INFO] [listener]: I heard: [Hello World: 2]
39 | ...
40 | ```
41 |
42 | ## Creating a `Dockerfile` to build ROS packages
43 |
44 | 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.
45 |
46 | ```dockerfile
47 | ARG FROM_IMAGE=%%IMAGE%%:foxy
48 | ARG OVERLAY_WS=/opt/ros/overlay_ws
49 |
50 | # multi-stage for caching
51 | FROM $FROM_IMAGE AS cacher
52 |
53 | # clone overlay source
54 | ARG OVERLAY_WS
55 | WORKDIR $OVERLAY_WS/src
56 | RUN echo "\
57 | repositories: \n\
58 | ros2/demos: \n\
59 | type: git \n\
60 | url: https://github.com/ros2/demos.git \n\
61 | version: ${ROS_DISTRO} \n\
62 | " > ../overlay.repos
63 | RUN vcs import ./ < ../overlay.repos
64 |
65 | # copy manifests for caching
66 | WORKDIR /opt
67 | RUN mkdir -p /tmp/opt && \
68 | find ./ -name "package.xml" | \
69 | xargs cp --parents -t /tmp/opt && \
70 | find ./ -name "COLCON_IGNORE" | \
71 | xargs cp --parents -t /tmp/opt || true
72 |
73 | # multi-stage for building
74 | FROM $FROM_IMAGE AS builder
75 |
76 | # install overlay dependencies
77 | ARG OVERLAY_WS
78 | WORKDIR $OVERLAY_WS
79 | COPY --from=cacher /tmp/$OVERLAY_WS/src ./src
80 | RUN . /opt/ros/$ROS_DISTRO/setup.sh && \
81 | apt-get update && rosdep install -y \
82 | --from-paths \
83 | src/ros2/demos/demo_nodes_cpp \
84 | src/ros2/demos/demo_nodes_py \
85 | --ignore-src \
86 | && rm -rf /var/lib/apt/lists/*
87 |
88 | # build overlay source
89 | COPY --from=cacher $OVERLAY_WS/src ./src
90 | ARG OVERLAY_MIXINS="release"
91 | RUN . /opt/ros/$ROS_DISTRO/setup.sh && \
92 | colcon build \
93 | --packages-select \
94 | demo_nodes_cpp \
95 | demo_nodes_py \
96 | --mixin $OVERLAY_MIXINS
97 |
98 | # source entrypoint setup
99 | ENV OVERLAY_WS $OVERLAY_WS
100 | RUN sed --in-place --expression \
101 | '$isource "$OVERLAY_WS/install/setup.bash"' \
102 | /ros_entrypoint.sh
103 |
104 | # run launch file
105 | CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"]
106 | ```
107 |
108 | 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.
109 |
110 | 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.
111 |
112 | 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.
113 |
114 | ## Deployment use cases
115 |
116 | 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.
117 |
118 | 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.
119 |
120 | 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.
121 |
122 | 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).
123 |
124 | ## Deployment suggestions
125 |
126 | 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:
127 |
128 | - `ros-core`: minimal ROS install
129 | - `ros-base`: basic tools and libraries (also tagged with distro name with LTS version as `latest`)
130 | - `ros1-bridge`: tools and libraries to run hybrid ROS 1 - ROS 2 systems and bridge messages between them
131 |
132 | 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.
133 |
134 | 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).
135 |
136 | ### Volumes
137 |
138 | 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.
139 |
140 | 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:
141 |
142 | ```console
143 | $ docker run -v "/home/ubuntu/.ros/:/root/.ros/" %%IMAGE%%
144 | ```
145 |
146 | ### Devices
147 |
148 | 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.
149 |
150 | ### Networks
151 |
152 | 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.
153 |
154 | 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).
155 |
156 | ## Deployment example
157 |
158 | ### Docker Compose
159 |
160 | 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.
161 |
162 | > 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:
163 |
164 | ```yaml
165 | services:
166 | talker:
167 | build: ./
168 | command: ros2 run demo_nodes_cpp talker
169 |
170 | listener:
171 | build: ./
172 | environment:
173 | - "PYTHONUNBUFFERED=1"
174 | command: ros2 run demo_nodes_py listener
175 | ```
176 |
177 | > 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:
178 |
179 | ```console
180 | $ docker compose up -d
181 | ```
182 |
183 | > Notice that a new network named `ros_demos_default` has been created, as can be shown further with:
184 |
185 | ```console
186 | $ docker network inspect ros_demos_default
187 | ```
188 |
189 | > We can monitor the logged output of each container, such as the listener node like so:
190 |
191 | ```console
192 | $ docker compose logs listener
193 | ```
194 |
195 | > Finally, we can stop and remove all the relevant containers using `docker compose` from the same directory:
196 |
197 | ```console
198 | $ docker compose stop
199 | $ docker compose rm
200 | ```
201 |
202 | > Note: the auto-generated network, `ros_demos_default`, will persist until you explicitly remove it using `docker compose down`.
203 |
204 | ### ROS 1 Bridge
205 |
206 | 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.
207 |
208 | ```dockerfile
209 | FROM %%IMAGE%%:noetic
210 |
211 | # install ros package
212 | RUN apt-get update && apt-get install -y \
213 | ros-${ROS_DISTRO}-ros-tutorials \
214 | ros-${ROS_DISTRO}-common-tutorials && \
215 | rm -rf /var/lib/apt/lists/*
216 |
217 | # launch ros package
218 | CMD ["roslaunch", "roscpp_tutorials", "talker_listener_launch"]
219 | ```
220 |
221 | 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.
222 |
223 | ```yaml
224 | services:
225 | ros1:
226 | build:
227 | context: ./
228 | dockerfile: ros1.Dockerfile
229 |
230 | ros2:
231 | build:
232 | context: ./
233 | dockerfile: ros2.Dockerfile
234 |
235 | bridge:
236 | image: ros:foxy-ros1-bridge
237 | environment:
238 | - "ROS_HOSTNAME=bridge"
239 | - "ROS_MASTER_URI=http://ros1:11311"
240 | command: ros2 run ros1_bridge dynamic_bridge
241 | ```
242 |
243 | # More Resources
244 |
245 | [ROS.org](http://www.ros.org/): Main ROS website
246 | [Q&A](https://answers.ros.org/questions/): Ask questions. Get answers
247 | [Forums](https://discourse.ros.org/): Hear the latest discussions
248 | [Blog](http://www.ros.org/news/): Stay up-to-date
249 | [Packages](https://index.ros.org/?search_packages=true): Discover indexed packages
250 | [OSRF](https://www.osrfoundation.org/): Open Source Robotics Foundation
251 |
252 | ## ROS 2
253 |
254 | [Index](https://docs.ros.org): ROS 2 Documentation
255 | [Design](https://design.ros2.org/): ROS 2 Design Articles
256 |
257 | ## ROS 1
258 |
259 | [Wiki](http://wiki.ros.org/Documentation): ROS 1 Documentation
260 |
```
--------------------------------------------------------------------------------
/yourls/logo.svg:
--------------------------------------------------------------------------------
```
1 | <svg width="256" height="105" viewBox="0 0 512 210" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><defs><path d="M24.896 15.55h23.08c1.601 0 2.9-1.3 2.9-2.905a2.903 2.903 0 00-2.9-2.906h-23.08c-1.602 0-2.9 1.3-2.9 2.906a2.903 2.903 0 002.9 2.905z" id="a"/><path id="b" d="M35.515 15.726H3v14.026h32.515v15.726L59.954 22.74 35.514 0z"/></defs><g fill="none" fill-rule="evenodd"><path d="M121.616 119.57a64.31 64.31 0 01-7.095 8.91 49.85 49.85 0 01-15.462 25.467 49.586 49.586 0 01-32.864 12.399 49.639 49.639 0 01-32.886-12.412 49.755 49.755 0 01-15.46-25.481 64.31 64.31 0 01-7.07-8.883C3.63 108.748-.034 96.074.054 82.762L.16 65.697c.099-27.418 22.356-49.599 49.78-49.599 5.576 0 11.063.929 16.258 2.723a49.777 49.777 0 0116.257-2.723c27.425 0 49.682 22.18 49.781 49.599l.106 17.065c.087 13.312-3.576 25.986-10.726 36.808zm28.233 28.606c-36.428 0-65.959-29.531-65.959-65.96 0-36.428 29.53-65.959 65.96-65.959 36.427 0 65.958 29.531 65.958 65.96 0 36.428-29.53 65.959-65.959 65.959zm99.855-131.919c27.406 0 49.622 22.217 49.622 49.622v16.31c0 36.433-29.608 65.933-66.092 65.933-36.483 0-66.092-29.5-66.092-65.932V65.88c0-27.406 22.217-49.623 49.622-49.623 5.654 0 11.215.958 16.47 2.807a49.615 49.615 0 0116.47-2.807zm49.463 131.812c-27.408 0-49.622-22.218-49.622-49.633l.004-16.642c.678-36.01 29.399-64.848 65.143-65.525a66.91 66.91 0 011.266-.012h11.845c27.406 0 49.622 22.217 49.622 49.622a49.47 49.47 0 01-11.534 31.809 49.701 49.701 0 01-18.875 13.953c-5.793 21.075-25.098 36.428-47.85 36.428zM377.957 0c27.405 0 49.622 22.217 49.622 49.622V98.47c0 27.426-22.207 49.652-49.622 49.652-27.406 0-49.623-22.216-49.623-49.622V49.622C328.334 22.217 350.551 0 377.957 0zm73.158 148.282h-21.73c-27.494 0-49.781-22.29-49.781-49.785 0-3.753.42-7.475 1.248-11.103a49.864 49.864 0 01-.825-17.584c3.618-30.603 29.596-53.712 60.462-53.712h21.73c27.494 0 49.78 22.29 49.78 49.785 0 3.753-.42 7.475-1.248 11.102a49.864 49.864 0 01.826 17.585c-3.619 30.603-29.597 53.712-60.462 53.712z" fill="#4393BB" fill-rule="nonzero"/><path d="M118.104 82.853c.07 10.485-2.772 20.399-8.367 28.868a50.206 50.206 0 01-8.334 9.667c-2.393 17.373-17.218 30.718-35.207 30.72-17.998-.002-32.87-13.38-35.218-30.733a50.205 50.205 0 01-8.319-9.654c-5.596-8.469-8.436-18.383-8.367-28.868l.106-17.088c.062-19.58 15.955-35.429 35.543-35.429a35.47 35.47 0 0116.257 3.93 35.47 35.47 0 0116.257-3.93c19.588 0 35.48 15.848 35.543 35.43l.106 17.087zm31.745 51.084c-28.564 0-51.72-23.156-51.72-51.72 0-28.565 23.156-51.721 51.72-51.721 28.565 0 51.72 23.156 51.72 51.72 0 28.565-23.155 51.721-51.72 51.721zm99.855-103.441c19.542 0 35.384 15.842 35.384 35.383v16.31c0 28.572-23.236 51.695-51.854 51.695-28.617 0-51.853-23.123-51.853-51.694V65.88c0-19.542 15.842-35.384 35.384-35.384a35.313 35.313 0 0116.47 4.06 35.311 35.311 0 0116.47-4.06zm49.463 103.335c-19.543 0-35.384-15.843-35.384-35.391l.005-16.51c.532-28.257 23.116-50.894 51.174-51.425.332-.006.664-.01.996-.01h11.845c19.542 0 35.384 15.843 35.384 35.384 0 17.258-12.355 31.63-28.703 34.754-1.129 18.524-16.51 33.198-35.317 33.198zm78.79-119.593c19.541 0 35.383 15.842 35.383 35.384V98.47c0 19.565-15.834 35.414-35.383 35.414-19.542 0-35.384-15.842-35.384-35.384V49.622c0-19.542 15.842-35.384 35.384-35.384zm119.805 73.85c0 1.58-.105 3.156-.314 4.719-2.728 23.461-22.634 41.236-46.333 41.236h-21.73c-19.63 0-35.543-15.915-35.543-35.546 0-3.817.607-7.556 1.772-11.103a35.53 35.53 0 01-1.772-11.101c0-1.58.105-3.157.314-4.72 2.728-23.461 22.633-41.237 46.333-41.237h21.73c19.63 0 35.543 15.916 35.543 35.547 0 3.816-.607 7.556-1.772 11.102a35.53 35.53 0 011.772 11.102z" fill="#FFF" fill-rule="nonzero"/><path d="M481.64 76.986a22.265 22.265 0 012.946 11.101c0 1.034-.071 2.064-.213 3.082-1.9 16.838-16.17 29.698-33.258 29.698h-21.73c-12.354 0-22.367-10.017-22.367-22.37 0-4.04 1.071-7.831 2.945-11.103a22.265 22.265 0 01-2.945-11.101c0-1.034.071-2.064.212-3.082 1.9-16.839 16.17-29.699 33.259-29.699h21.73c12.354 0 22.367 10.017 22.367 22.37 0 4.041-1.071 7.832-2.945 11.104z" fill="#4393BB" fill-rule="nonzero"/><path d="M454.09 88.087a8.129 8.129 0 1116.156 1.285c-.992 9.694-9.179 17.257-19.131 17.257h-21.73a8.13 8.13 0 01-8.129-8.132 8.13 8.13 0 018.13-8.132h22.42c1.258 0 2.28-1.02 2.284-2.278zm-16.576-11.794a8.129 8.129 0 11-16.157-1.285c.993-9.695 9.18-17.257 19.132-17.257h21.73a8.13 8.13 0 018.128 8.132 8.13 8.13 0 01-8.128 8.132h-22.42a2.285 2.285 0 00-2.285 2.278z" fill="#FFF"/><path d="M355.749 49.622c0-12.265 9.943-22.208 22.208-22.208 12.265 0 22.207 9.943 22.207 22.208V98.47c0 12.295-9.942 22.238-22.207 22.238s-22.208-9.943-22.208-22.208V49.622z" fill="#4393BB" fill-rule="nonzero"/><path d="M369.828 49.622a8.129 8.129 0 1116.257 0V98.5a8.129 8.129 0 11-16.257-.053V49.622z" fill="#FFF"/><path d="M321.375 98.448c0 12.265-9.943 22.207-22.208 22.207-12.265 0-22.208-9.943-22.208-22.212l.005-16.388c.397-21.079 17.298-37.98 38.247-38.376.249-.005.498-.007.747-.007h11.845c12.265 0 22.208 9.942 22.208 22.207s-9.943 22.208-22.208 22.208h-6.427l-.001 10.361z" fill="#4393BB" fill-rule="nonzero"/><path d="M307.296 98.447l.001-16.257a8.182 8.182 0 018.183-8.182h12.323a8.129 8.129 0 100-16.257h-11.845c-.16 0-.32.001-.48.004-13.383.254-24.188 11.027-24.44 24.408v16.284a8.129 8.129 0 0016.258 0z" fill="#FFF"/><g><path d="M249.704 43.672c12.265 0 22.208 9.942 22.208 22.207v16.31c0 21.294-17.337 38.52-38.678 38.52-21.34 0-38.677-17.226-38.677-38.52V65.88c0-12.265 9.943-22.207 22.208-22.207 6.532 0 12.406 2.82 16.47 7.31 4.063-4.49 9.937-7.31 16.47-7.31z" fill="#4393BB" fill-rule="nonzero"/><path d="M241.576 82.19h-.006a8.341 8.341 0 01-16.67 0l-.007-16.31a8.129 8.129 0 10-16.257 0v16.31c0 13.497 11.013 24.439 24.598 24.439 13.586 0 24.599-10.942 24.599-24.44V65.88a8.129 8.129 0 00-16.257 0v16.31z" fill="#FFF"/></g><g><path d="M149.85 120.761c-21.289 0-38.546-17.257-38.546-38.545 0-21.287 17.257-38.544 38.545-38.544s38.545 17.257 38.545 38.544c0 21.288-17.257 38.545-38.545 38.545z" fill="#4393BB" fill-rule="nonzero"/><path d="M149.85 106.523c-13.425 0-24.307-10.883-24.307-24.307s10.882-24.306 24.306-24.306c13.424 0 24.306 10.882 24.306 24.306 0 13.424-10.882 24.307-24.306 24.307zm.026-16.204a8.129 8.129 0 100-16.258 8.129 8.129 0 000 16.258z" fill="#FFF"/></g><g><path d="M82.455 43.512c12.335 0 22.337 9.985 22.367 22.313l.106 17.113c.053 7.883-2.037 15.242-6.184 21.52-2.704 4.091-6.145 7.533-10.18 10.299v1.686c0 12.473-10.012 22.487-22.367 22.488-12.353 0-22.366-10.014-22.366-22.367v-1.807c-4.035-2.766-7.475-6.208-10.179-10.3-4.148-6.277-6.237-13.636-6.184-21.52l.106-17.112c.03-12.328 10.032-22.313 22.367-22.313 6.404 0 12.18 2.692 16.257 7.005a22.304 22.304 0 0116.257-7.005z" fill="#4393BB" fill-rule="nonzero"/><path d="M58.07 116.564a8.129 8.129 0 0016.256 0v-10.387a29.353 29.353 0 004.202-1.926c3.337-1.887 6.195-4.403 8.336-7.642 2.533-3.834 3.861-8.412 3.826-13.579l-.106-17.15a8.129 8.129 0 10-16.258 0V81.5c.004.537-.01 1.017-.047 1.455a8.129 8.129 0 11-16.162 0 16.127 16.127 0 01-.047-1.456V65.88a8.129 8.129 0 10-16.258 0l-.106 17.151c-.035 5.167 1.293 9.745 3.826 13.579 2.14 3.24 4.999 5.755 8.336 7.642 1.32.746 2.757 1.39 4.202 1.926v10.387z" fill="#FFF"/></g><g><path d="M117.946 158.852h16.043c11.034 0 19.979 8.945 19.979 19.979 0 11.034-8.945 19.978-19.979 19.978h-16.043c-11.034 0-19.978-8.944-19.978-19.978s8.944-19.979 19.978-19.979zm0 12.815a7.164 7.164 0 100 14.328h16.043a7.164 7.164 0 000-14.328h-16.043z" fill="#026090"/><path d="M117.52 160.501c-10.123 0-18.329 8.207-18.329 18.33 0 10.123 8.206 18.33 18.33 18.33h16.894c10.123 0 18.33-8.207 18.33-18.33 0-10.123-8.207-18.33-18.33-18.33H117.52zm0-2.71h16.895c11.62 0 21.04 9.42 21.04 21.04s-9.42 21.039-21.04 21.039H117.52c-11.62 0-21.039-9.42-21.039-21.04 0-11.619 9.42-21.038 21.04-21.038zm0 16.205a4.835 4.835 0 000 9.67h16.895a4.835 4.835 0 100-9.67H117.52zm0-2.71h16.895a7.544 7.544 0 010 15.089H117.52a7.544 7.544 0 010-15.089z" fill="#FFF" fill-rule="nonzero"/><path d="M180.123 159.292h15.69c10.791 0 19.539 8.748 19.539 19.539 0 10.79-8.748 19.539-19.539 19.539h-15.69c-10.791 0-19.54-8.748-19.54-19.54 0-10.79 8.749-19.538 19.54-19.538zm0 12.532a7.006 7.006 0 100 14.013h15.69a7.006 7.006 0 100-14.013h-15.69z" fill="#026090"/><path d="M179.52 160.501c-10.123 0-18.329 8.207-18.329 18.33 0 10.123 8.206 18.33 18.33 18.33h16.894c10.123 0 18.33-8.207 18.33-18.33 0-10.123-8.207-18.33-18.33-18.33H179.52zm0-2.71h16.895c11.62 0 21.04 9.42 21.04 21.04s-9.42 21.039-21.04 21.039H179.52c-11.62 0-21.039-9.42-21.039-21.04 0-11.619 9.42-21.038 21.04-21.038zm0 16.205a4.835 4.835 0 000 9.67h16.895a4.835 4.835 0 100-9.67H179.52zm0-2.71h16.895a7.544 7.544 0 010 15.089H179.52a7.544 7.544 0 010-15.089z" fill="#FFF" fill-rule="nonzero"/><path d="M241.946 158.852h16.043c11.034 0 19.979 8.945 19.979 19.979 0 11.034-8.945 19.978-19.979 19.978h-16.043c-11.034 0-19.978-8.944-19.978-19.978s8.944-19.979 19.978-19.979zm0 12.815a7.164 7.164 0 100 14.328h16.043a7.164 7.164 0 000-14.328h-16.043z" fill="#026090"/><path d="M241.52 160.501c-10.123 0-18.329 8.207-18.329 18.33 0 10.123 8.206 18.33 18.33 18.33h16.894c10.123 0 18.33-8.207 18.33-18.33 0-10.123-8.207-18.33-18.33-18.33H241.52zm0-2.71h16.895c11.62 0 21.04 9.42 21.04 21.04s-9.42 21.039-21.04 21.039H241.52c-11.62 0-21.039-9.42-21.039-21.04 0-11.619 9.42-21.038 21.04-21.038zm0 16.205a4.835 4.835 0 000 9.67h16.895a4.835 4.835 0 100-9.67H241.52zm0-2.71h16.895a7.544 7.544 0 010 15.089H241.52a7.544 7.544 0 010-15.089z" fill="#FFF" fill-rule="nonzero"/><path d="M305.09 159.21h15.756c10.837 0 19.622 8.784 19.622 19.62 0 10.837-8.785 19.622-19.622 19.622H305.09c-10.836 0-19.621-8.785-19.621-19.621 0-10.837 8.785-19.622 19.621-19.622zm0 12.585a7.036 7.036 0 100 14.072h15.756a7.036 7.036 0 000-14.072H305.09z" fill="#026090"/><path d="M304.52 160.501c-10.123 0-18.329 8.207-18.329 18.33 0 10.123 8.206 18.33 18.33 18.33h16.894c10.123 0 18.33-8.207 18.33-18.33 0-10.123-8.207-18.33-18.33-18.33H304.52zm0-2.71h16.895c11.62 0 21.04 9.42 21.04 21.04s-9.42 21.039-21.04 21.039H304.52c-11.62 0-21.039-9.42-21.039-21.04 0-11.619 9.42-21.038 21.04-21.038zm0 16.205a4.835 4.835 0 000 9.67h16.895a4.835 4.835 0 100-9.67H304.52zm0-2.71h16.895a7.544 7.544 0 010 15.089H304.52a7.544 7.544 0 010-15.089z" fill="#FFF" fill-rule="nonzero"/><path d="M137.975 185.02h38.465a6.19 6.19 0 000-12.379h-38.465a6.19 6.19 0 000 12.38z" stroke="#FFF" stroke-width="2.71"/><path d="M137.975 183.665h38.465a4.835 4.835 0 100-9.669h-38.465a4.835 4.835 0 000 9.67z" fill="#026090"/><path d="M199.976 186.375a7.544 7.544 0 010-15.088h38.465a7.544 7.544 0 110 15.088h-38.465z" fill="#FFF" fill-rule="nonzero"/><path d="M199.976 183.665h38.465a4.835 4.835 0 100-9.669h-38.465a4.835 4.835 0 000 9.67z" fill="#026090"/><path d="M199.976 183.665h38.465a4.835 4.835 0 100-9.669h-38.465a4.835 4.835 0 000 9.67z"/><path d="M261.977 186.375a7.544 7.544 0 110-15.088h38.465a7.544 7.544 0 010 15.088h-38.465z" fill="#FFF" fill-rule="nonzero"/><path d="M261.977 183.665h38.465a4.835 4.835 0 000-9.669h-38.465a4.835 4.835 0 000 9.67z"/><path d="M261.977 183.665h38.465a4.835 4.835 0 000-9.669h-38.465a4.835 4.835 0 000 9.67z" fill="#026090"/><g><path d="M469.73 166.686h9.736c6.696 0 12.124 5.437 12.124 12.145 0 6.707-5.428 12.144-12.124 12.144h-9.737c-6.696 0-12.124-5.437-12.124-12.144 0-6.708 5.428-12.145 12.124-12.145zm0 7.79a4.351 4.351 0 00-4.348 4.355 4.351 4.351 0 004.347 4.355h9.737a4.351 4.351 0 004.347-4.355 4.351 4.351 0 00-4.347-4.355h-9.737z" fill="#026090"/><path d="M469.529 167.815c-6.074 0-10.998 4.932-10.998 11.016s4.924 11.016 10.998 11.016h10.137c6.074 0 10.998-4.932 10.998-11.016s-4.924-11.016-10.998-11.016h-10.137zm0-1.629h10.137c6.972 0 12.623 5.661 12.623 12.645 0 6.983-5.651 12.644-12.623 12.644h-10.137c-6.972 0-12.623-5.66-12.623-12.644s5.651-12.645 12.623-12.645zm0 9.74c-1.602 0-2.9 1.3-2.9 2.905a2.903 2.903 0 002.9 2.905h10.137c1.602 0 2.9-1.3 2.9-2.905a2.903 2.903 0 00-2.9-2.906h-10.137zm0-1.63h10.137a4.53 4.53 0 014.527 4.535 4.53 4.53 0 01-4.527 4.534h-10.137a4.53 4.53 0 01-4.527-4.534 4.53 4.53 0 014.527-4.534z" fill="#FFF" fill-rule="nonzero"/><path d="M432.574 167.038h9.454c6.502 0 11.773 5.28 11.773 11.793 0 6.513-5.27 11.793-11.773 11.793h-9.454c-6.502 0-11.773-5.28-11.773-11.793 0-6.513 5.271-11.793 11.773-11.793zm0 7.564a4.225 4.225 0 00-4.221 4.229 4.225 4.225 0 004.221 4.228h9.454a4.225 4.225 0 004.222-4.228 4.225 4.225 0 00-4.222-4.229h-9.454z" fill="#026090"/><path d="M432.233 167.815c-6.074 0-10.998 4.932-10.998 11.016s4.924 11.016 10.998 11.016h10.137c6.074 0 10.997-4.932 10.997-11.016s-4.923-11.016-10.997-11.016h-10.137zm0-1.629h10.137c6.971 0 12.623 5.661 12.623 12.645 0 6.983-5.652 12.644-12.623 12.644h-10.137c-6.972 0-12.624-5.66-12.624-12.644s5.652-12.645 12.624-12.645zm0 9.74c-1.602 0-2.901 1.3-2.901 2.905a2.903 2.903 0 002.9 2.905h10.138c1.602 0 2.9-1.3 2.9-2.905a2.903 2.903 0 00-2.9-2.906h-10.137zm0-1.63h10.137a4.53 4.53 0 014.526 4.535 4.53 4.53 0 01-4.526 4.534h-10.137a4.53 4.53 0 01-4.527-4.534 4.53 4.53 0 014.527-4.534z" fill="#FFF" fill-rule="nonzero"/><path d="M444.505 183.365a4.53 4.53 0 01-4.526-4.534 4.53 4.53 0 014.526-4.534h23.08a4.53 4.53 0 014.526 4.534 4.53 4.53 0 01-4.526 4.534h-23.08z" fill="#FFF" fill-rule="nonzero"/><g transform="translate(419.61 166.186)"><use fill="#026090" xlink:href="#a"/><path stroke="#FFF" stroke-width="1.626" d="M24.896 16.363h23.08a3.716 3.716 0 003.713-3.718 3.716 3.716 0 00-3.714-3.719H24.896a3.716 3.716 0 00-3.714 3.719 3.716 3.716 0 003.714 3.718z"/></g></g><g fill-rule="nonzero"><path d="M381.463 171.818v-12.38c0-2.923 3.486-4.442 5.627-2.45l24.44 22.74a3.347 3.347 0 010 4.9l-24.44 22.74c-2.14 1.991-5.627.473-5.627-2.451v-12.38h-29.167a3.347 3.347 0 01-3.348-3.346v-14.026a3.347 3.347 0 013.348-3.347h29.167z"/><g stroke-linecap="square" stroke-linejoin="round" transform="translate(348.948 156.039)"><use fill="#4393BB" fill-rule="evenodd" xlink:href="#b"/><path stroke="#FFF" stroke-width="1.806" d="M34.611 14.823H2.097v15.832H34.61v16.897l1.519-1.413L60.57 23.4l.71-.661-.71-.661L36.13-.662 34.61-2.073v16.897z"/></g></g></g></g></svg>
```
--------------------------------------------------------------------------------
/convertigo/content.md:
--------------------------------------------------------------------------------
```markdown
1 | # What is Convertigo Low Code Platform ?
2 |
3 | Convertigo is an open source fullstack Low Code & No Code platform. The platform is used to build Enterprise Web & Mobile apps in a few days. Convertigo platform is composed of several components:
4 |
5 | 1. **Convertigo Server**: The back-end server part. Handles back-end connectors, micro-services execution, offline data device synchronization and serves Web & Mobile Web apps. Runs as a Docker container with the `convertigo` image
6 | 2. **Convertigo Studio**: Runs on a Windows or a MacOS workstation, Eclipse based IDE, used to program Back-end micro-services workflows and use the "Mobile Builder" edition to build Mobile & Web apps UIs in a MXDP (Multi eXperience Development Platform) Low code mode. Can be directly downloaded from [Convertigo](https://www.convertigo.com/get-started-page)
7 | 3. **Convertigo NoCode Studio**: The No Code App Builder to build form based apps as PWAs or Web applications with a Web Based NoCode studio intented for non technical developpers (Citizen Developpers)
8 |
9 | Convertigo Community edition brought to you by Convertigo SA (Paris & San Francisco). The platform is currently used by more than 100K developers worldwide, building enterprise class mobile apps.
10 |
11 | > [www.convertigo.com](https://www.convertigo.com)
12 |
13 | %%LOGO%%
14 |
15 | # How to use this image
16 |
17 | ## Quick start
18 |
19 | ```console
20 | $ docker run --name C8O -d -p 28080:28080 %%IMAGE%%
21 | ```
22 |
23 | This will start a container running the minimum Convertigo server. Convertigo uses images' **/workspace** directory to store configuration file and deployed projects as an Docker volume.
24 |
25 | You can access the Server admin console on `http://[dockerhost]:28080/convertigo` and login using the default credentials: `admin / admin`.
26 |
27 | The Server can also be accessed by HTTPS on `https://[dockerhost]:28443/convertigo` if SSL is configured (see the **HTTPS** section below).
28 |
29 | ## Link Convertigo to a CouchDB database for FullSync (Convertigo EE only)
30 |
31 | Convertigo FullSync module uses Apache CouchDB 3.2.2 as NoSQL repository. You can use the **[couchdb](https://hub.docker.com/_/couchdb/)** docker image and link to it convertigo this way
32 |
33 | Launch CouchDB container and name it 'fullsync'
34 |
35 | ```console
36 | $ docker run -d --name fullsync couchdb:3.2.2
37 | ```
38 |
39 | Then launch Convertigo and link it to the running 'fullsync' container. Convertigo Low Code sever will automatically use it as its fullsync repository.
40 |
41 | ```console
42 | $ docker run -d --name C8O --link fullsync:couchdb -p 28080:28080 %%IMAGE%%
43 | ```
44 |
45 | ## Use embedded PouchDB as FullSync engine (not for production)
46 |
47 | Convertigo FullSync is designed to use CouchDB server or cluster. Convertigo FullSync is also compatible with PouchDB but only for little projects or tests. Internet access is required to enable this feature.
48 |
49 | It can be enabled directly at startup:
50 |
51 | ```console
52 | $ docker run -d --name C8O -e JAVA_OPTS="-Dconvertigo.engine.fullsync.pouchdb=true" -p 28080:28080 %%IMAGE%%
53 | ```
54 |
55 | ## Link Convertigo Low Code Server to a Billing & Analytics database
56 |
57 | ### MySQL
58 |
59 | MySQL is the recommended database for holding Convertigo Low Code server analytics. You can use this command to run convertigo and link it to a running MySQL container. Change `[mysql-container]` to the container name, and `[username for the c8oAnalytics db]`, `[password for specified db user]` with the values for your MySQL configuration.
60 |
61 | ```console
62 | $ docker run -d --name C8O --link [mysql-container]:mysql -p 28080:28080 \
63 | -e JAVA_OPTS="-Dconvertigo.engine.billing.enabled=true \
64 | -Dconvertigo.engine.billing.persistence.jdbc.username=[username for the c8oAnalytics db] \
65 | -Dconvertigo.engine.billing.persistence.jdbc.password=[password for specified db user] \
66 | -Dconvertigo.engine.billing.persistence.jdbc.url=jdbc:mysql://mysql:3306/c8oAnalytics" \
67 | %%IMAGE%%
68 | ```
69 |
70 | ## Where is Convertigo Low Code server storing deployed projects
71 |
72 | Projects are deployed in the Convertigo workspace, a simple file system directory. You can map the docker container **/workspace** to your physical system by using:
73 |
74 | ```console
75 | $ docker run --name C8O -v $(pwd):/workspace -d -p 28080:28080 %%IMAGE%%
76 | ```
77 |
78 | You can share the same workspace by all Convertigo containers. In this case, when you deploy a project on a Convertigo container, it will be seen by others. This is the best way to build multi-instance load balanced Convertigo server farms.
79 |
80 | **Be sure to have a really fast file sharing between instances !!! We have experienced that Azure File Share is not fast enough**
81 |
82 | To avoid log and cache mixing, you have to add 2 variables for instance specific paths:
83 |
84 | ```console
85 | -Dconvertigo.engine.cache_manager.filecache.directory=/workspace/cache/[instance name]
86 | -Dconvertigo.engine.log4j.appender.CemsAppender.File=/workspace/logs/[instance name]/engine.log
87 | ```
88 |
89 | ## Make image with pre-deployed projects
90 |
91 | If you want to make a vertical image ready to start with your application inside, you have to have your built projects **.car** files next to your `Dockerfile`:
92 |
93 | ```console
94 | FROM %%IMAGE%%
95 | COPY myProject.car /usr/local/tomcat/webapps/convertigo/WEB-INF/default_user_workspace/projects/
96 | COPY myDependency.car /usr/local/tomcat/webapps/convertigo/WEB-INF/default_user_workspace/projects/
97 | ```
98 |
99 | ## Migrate from an earlier version of Convertigo Low Code Platform
100 |
101 | - Stop the container to perform a backup. And just back the workspace directory. This will backup all the projects definitions and some project data.
102 | - Start a new Convertigo docker container mapping the workspace
103 | - All the workspace (Projects) will be automatically migrated to the new Convertigo MBaaS version
104 |
105 | ## Security
106 |
107 | The default administration account of a Convertigo server is **admin** / **admin** and the **testplatform** is anonymous.
108 |
109 | These accounts can be configured through the **administration console** and saved in the **workspace**.
110 |
111 | ### `CONVERTIGO_ADMIN_USER` and `CONVERTIGO_ADMIN_PASSWORD` Environment variables
112 |
113 | You can change the default administration account :
114 |
115 | ```console
116 | $ docker run -d --name C8O -e CONVERTIGO_ADMIN_USER=administrator -e CONVERTIGO_ADMIN_PASSWORD=s3cret -p 28080:28080 %%IMAGE%%
117 | ```
118 |
119 | ### `CONVERTIGO_TESTPLATFORM_USER` and `CONVERTIGO_TESTPLATFORM_PASSWORD` Environment variables
120 |
121 | You can lock the **testplatform** by setting the account :
122 |
123 | ```console
124 | $ docker run -d --name C8O -e CONVERTIGO_TESTPLATFORM_USER=tp_user -e CONVERTIGO_TESTPLATFORM_PASSWORD=s3cret -p 28080:28080 %%IMAGE%%
125 | ```
126 |
127 | ## HTTPS / SSL Configuration
128 |
129 | In many cases, the Convertigo instance is behind a reverse proxy that handles HTTPS / SSL configuration. But you can configure the container to manage existing SSL certificates or dynamically generate one.
130 |
131 | If the SSL configuration is correct, the Convertigo Server will listen **HTTP** on port `28080` and **HTTPS** on port `28443`.
132 |
133 | ### Provide existing certificate using the /ssl mount point
134 |
135 | If you have an existing certificate and a private key, you can put them in **PEM** format in a folder (or in a Kubernetes secret):
136 |
137 | - `key.pem` : the private key in PEM format (no password)
138 | - `cert.pem` : the server certificate in PEM format, can also contain the full chain of certificates
139 | - `chain.pem` : the optional chain of certificates not included in `cert.pem` using the PEM format
140 |
141 | ```console
142 | $ docker run -d --name C8O -v <my SSL folder>:/ssl -p 28443:28443 %%IMAGE%%
143 | ```
144 |
145 | If you want to expose both **HTTP** and **HTTPS** you can expose both **ports**:
146 |
147 | ```console
148 | $ docker run -d --name C8O -v <my SSL folder>:/ssl -p 28080:28080 -p 28443:28443 %%IMAGE%%
149 | ```
150 |
151 | ### Provide existing certificate using environment variables
152 |
153 | If you cannot mount a volume, you can probably add environment variables of previously described files. Content cannot be set directly in a variable but their base64 version can. Here are the variables to configure:
154 |
155 | - `SSL_KEY_B64` : the private key in base64 PEM format (no password)
156 | - `SSL_CERT_B64` : the server certificate in base64 PEM format, can also contain the full chain of certificates
157 | - `SSL_CHAIN_B64` : the optional chain of certificates not included in `cert.pem` using the base64 PEM format
158 |
159 | ```console
160 | $ SSL_KEY_B64=$(base64 key.pem)
161 | $ SSL_CERT_B64=$(base64 cert.pem)
162 | $ SSL_CHAIN_B64=$(base64 chain.pem)
163 | $ docker run -d --name C8O -e SSL_KEY_B64="$SSL_KEY_B64" -e SSL_CERT_B64="$SSL_CERT_B64" -e SSL_CHAIN_B64="$SSL_CHAIN_B64" -p 28443:28443 %%IMAGE%%
164 | ```
165 |
166 | ### Generate and use a self-signed certificate
167 |
168 | If you don't have certificate file, you can dynamically generate one for the first start. This will be an untrusted certificate for Browsers and HTTPS clients. This shouldn't be used for production environment.
169 |
170 | Use the `SSL_SELFSIGNED` environment variable to indicate for what domain you want generate certificate.
171 |
172 | ```console
173 | $ docker run -d --name C8O -e SSL_SELFSIGNED=mycomputer -p 28443:28443 %%IMAGE%%
174 | ```
175 |
176 | Generated files can be retrieved if the `/ssl` mount point is configured on folder without `cert.pem` nor `key.pem`.
177 |
178 | ```console
179 | $ docker run -d --name C8O -v <my empty SSL folder>:/ssl -e SSL_SELFSIGNED=mycomputer -p 28443:28443 %%IMAGE%%
180 | ```
181 |
182 | ## `JAVA_OPTS` Environment variable
183 |
184 | Convertigo is based on a **Java** process with some defaults **JVM** options. You can override our defaults **JVM** options with you own.
185 |
186 | Add any **Java JVM** options such as -D[something] :
187 |
188 | ```console
189 | $ docker run -d --name C8O -e JAVA_OPTS="-DjvmRoute=server1" -p 28080:28080 %%IMAGE%%
190 | ```
191 |
192 | [Here the list of convertigo specific properties](https://www.convertigo.com/documentation/latest/operating-guide/appendixes/#list-of-convertigo-java-system-properties) (don't forget the `-Dconvertigo.engine.` prefix).
193 |
194 | ## `LOG_STDOUT` and `LOG_FILE` Environment variables
195 |
196 | Convertigo generates many logs in a **engine.log** file that can be consulted via the Convertigo Administration Console. In some environments, it's easiest to read logs from the container's standard output. Set this property `true` to enable console output. The default value is `false`.
197 |
198 | Log file still exists until you add the `LOG_FILE=false` environment variable :
199 |
200 | ```console
201 | docker run -d --name C8O -e LOG_STDOUT=true -e LOG_FILE=false -p 28080:28080 convertigo
202 | ```
203 |
204 | ## `JXMX` Environment variable
205 |
206 | Convertigo tries to allocate this amount of memory in the container and will automatically reduce it until the value is compatible for the Docker memory constraints. Once the best value found, it is used as `-Xmx=${JXMX}m` parameter for the JVM.
207 |
208 | The default `JXMX` value is `2048` and can be defined :
209 |
210 | ```console
211 | $ docker run -d --name C8O -e JXMX="4096" -p 28080:28080 %%IMAGE%%
212 | ```
213 |
214 | ## `COOKIE_PATH` Environment variable
215 |
216 | Convertigo generates a `JSESSIONID` to maintain the user session and stores in a **cookie**. The **cookie** is set for the server path `/` by default. In case of a front server with multiple services for different paths, you can set a path restriction for the **cookie** with the `JSESSIONID`. Just define the `COOKIE_PATH` environment variable with a compatible path.
217 |
218 | The default `COOKIE_PATH` value is `/` and can be defined :
219 |
220 | ```console
221 | $ docker run -d --name C8O -e COOKIE_PATH="/convertigo" -p 28080:28080 %%IMAGE%%
222 | ```
223 |
224 | ## `COOKIE_SECURE` Environment variable
225 |
226 | Convertigo uses a **cookie** to maintain sessions. Requests on port `28080` are **HTTP** but we advise to use an **HTTPS** front for production (nginx, kubernetes ingress, ...). In this case, you can secure your cookies to be used only with secured connections by adding the `Secure` flag.
227 |
228 | The Secure flag can be enabled by setting the `COOKIE_SECURE` environment variable to `true`. Once enabled, cookies and sessions aren't working through an **HTTP** connection.
229 |
230 | The default `COOKIE_SECURE` value is `false` and can be defined :
231 |
232 | ```console
233 | $ docker run -d --name C8O -e COOKIE_SECURE="true" -p 28080:28080 %%IMAGE%%
234 | ```
235 |
236 | **Note :** if you have set the **SSL** configuration and you access the **HTTPS 28443** port, cookies are automatically `Secure`.
237 |
238 | ## `COOKIE_SAMESITE` Environment variable
239 |
240 | Allow to configure the **SameSite** parameter for generated cookies. Can be empty, `none`, `lax` or `strict`.
241 |
242 | The default `COOKIE_SAMESITE` value is **empty** and can be defined this way:
243 |
244 | ```console
245 | $ docker run -d --name C8O -e COOKIE_SAMESITE=lax -p 28080:28080 %%IMAGE%%
246 | ```
247 |
248 | ## `SESSION_TIMEOUT` Environment variable
249 |
250 | Allow to configure the default Tomcat **session-timeout** in minutes. This value is used for non-project calls (Administration console, Fullsync...). This value is overridden by each projects' calls (Sequence, Transaction ...).
251 |
252 | The default `SESSION_TIMEOUT` value is **30** and can be defined this way:
253 |
254 | ```console
255 | $ docker run -d --name C8O -e SESSION_TIMEOUT=5 -p 28080:28080 %%IMAGE%%
256 | ```
257 |
258 | ## `DISABLE_SUDO` Environment variable
259 |
260 | The image includes **sudo** command line, configured to allow the **convertigo** user to use it without password and to perform some **root** action inside the container. This variable allows to disable this permission.
261 |
262 | The default `DISABLE_SUDO` value is **empty** and can be defined this way:
263 |
264 | ```console
265 | $ docker run -d --name C8O -e DISABLE_SUDO=true -p 28080:28080 %%IMAGE%%
266 | ```
267 |
268 | ## `ENABLE_JDWP_DEBUG` Environment variable
269 |
270 | Convertigo operates using the JVM (Java Virtual Machine). To enable remote debugging of the JVM, it's necessary to start it with specific options. By default, this configuration is not enabled. However, if you wish to automatically activate remote debugging over the JDWP port 8000, set the `ENABLE_JDWP_DEBUG` value to **true**.
271 |
272 | The default `ENABLE_JDWP_DEBUG` value is **false** and can be defined this way:
273 |
274 | ```console
275 | $ docker run -d –name C8O -e ENABLE_JDWP_DEBUG=true -p 28080:28080 %%IMAGE%%
276 | ```
277 |
278 | ## Pre-configurated Docker Compose file
279 |
280 | You can use [this Docker Compose file](https://github.com/convertigo/docker/blob/master/compose/mbaas/docker-compose.yml) to run a complete Convertigo Low Code server with FullSync repository and MySQL analytics in a few command lines.
281 |
282 | ```console
283 | $ mkdir c8oMBaaS
284 | $ cd c8oMBaaS
285 | $ wget https://raw.githubusercontent.com/convertigo/docker/master/compose/mbaas/docker-compose.yml
286 | $ docker compose up -d
287 | ```
288 |
```
--------------------------------------------------------------------------------
/mariadb/content.md:
--------------------------------------------------------------------------------
```markdown
1 | # What is MariaDB?
2 |
3 | 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.
4 |
5 | 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.
6 |
7 | %%LOGO%%
8 |
9 | # How to use this image
10 |
11 | The %%IMAGE%% has a number of tags, and of note is `latest`, as the latest stable version, and `lts`, as the last long term support release.
12 |
13 | ## Running the container
14 |
15 | ### Configuration
16 |
17 | #### Port binding
18 |
19 | 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:
20 |
21 | ```console
22 | $ docker run --name some-%%REPO%% -p 3306:3306 %%IMAGE%%:latest
23 | ```
24 |
25 | ### Starting using a minimal configuration
26 |
27 | The environment variables required to use this image involves the setting of the root user password:
28 |
29 | ```console
30 | $ docker run --detach --name some-%%REPO%% --env MARIADB_ROOT_PASSWORD=my-secret-pw %%IMAGE%%:latest
31 | ```
32 |
33 | or:
34 |
35 | ```console
36 | $ docker run --detach --name some-%%REPO%% --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 %%IMAGE%%:latest
37 | ```
38 |
39 | or:
40 |
41 | ```console
42 | $ docker run --detach --name some-%%REPO%% --env MARIADB_RANDOM_ROOT_PASSWORD=1 %%IMAGE%%:latest
43 | ```
44 |
45 | ... where the container logs will contain the generated root password.
46 |
47 | ## %%COMPOSE%%
48 |
49 | Run `docker compose up`, wait for it to initialize completely, and visit `http://localhost:8080` or `http://host-ip:8080` (as appropriate).
50 |
51 | ### Start a `%%IMAGE%%` server instance with user, password and database
52 |
53 | Starting a MariaDB instance with a user, password, and a database:
54 |
55 | ```console
56 | $ docker run --detach --name some-%%REPO%% --env MARIADB_USER=example-user --env MARIADB_PASSWORD=my_cool_secret --env MARIADB_DATABASE=exmple-database --env MARIADB_ROOT_PASSWORD=my-secret-pw %%IMAGE%%:latest
57 | ```
58 |
59 | ### Start a `%%IMAGE%%` server instance in a network
60 |
61 | As applications talk to MariaDB, MariaDB needs to start in the same network as the application:
62 |
63 | ```console
64 | $ docker network create some-network
65 | $ docker run --detach --network some-network --name some-%%REPO%% --env MARIADB_USER=example-user --env MARIADB_PASSWORD=my_cool_secret --env MARIADB_ROOT_PASSWORD=my-secret-pw %%IMAGE%%:latest
66 | $ docker run --detach --network some-network --name some-application --env APP_DB_HOST=some-%%REPO%% --env APP_DB_USER=example-user --env APP_DB_PASSWD=my_cool_secret some-application
67 | ```
68 |
69 | ... where `some-network` is a newly created network (other than `bridge` as the default network), `some-%%REPO%%` 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.
70 |
71 | ## Connect to MariaDB from the MariaDB command line client
72 |
73 | The following command starts another `%%IMAGE%%` container instance and runs the `mariadb` command line client against your original `%%IMAGE%%` container, allowing you to execute SQL statements against your database instance:
74 |
75 | ```console
76 | $ docker run -it --network some-network --rm %%IMAGE%% mariadb -h some-%%REPO%% -u example-user
77 | ```
78 |
79 | ... where `some-%%REPO%%` is the name of your original `%%IMAGE%%` container (connected to the `some-network` Docker network).
80 |
81 | This image can also be used as a client for non-Docker or remote instances:
82 |
83 | ```console
84 | $ docker run -it --rm %%IMAGE%% mariadb --host <server container IP> --user example-user --password --database test
85 | ```
86 |
87 | That will give you a standard MariaDB prompt. You can test it with:
88 |
89 | ```console
90 | MariaDB [(none)]> \s
91 | --------------
92 | client/mariadb Ver 15.1 Distrib 10.6.16-MariaDB, for Linux (x86_64) using EditLine wrapper
93 |
94 | Connection id: 20
95 | Current database: test
96 | Current user: example-user@bark
97 | SSL: Not in use
98 | Current pager: stdout
99 | Using outfile: ''
100 | Using delimiter: ;
101 | Server: MariaDB
102 | Server version: 10.6.16-MariaDB Source distribution
103 | Protocol version: 10
104 | Connection: 192.168.178.73 via TCP/IP
105 | Server characterset: latin1
106 | Db characterset: latin1
107 | Client characterset: utf8mb3
108 | Conn. characterset: utf8mb3
109 | TCP port: 3306
110 | Uptime: 6 min 4 sec
111 |
112 | Threads: 1 Questions: 32 Slow queries: 0 Opens: 20 Open tables: 13 Queries per second avg: 0.087
113 | --------------
114 | ```
115 |
116 | ... 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.
117 |
118 | 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/).
119 |
120 | ## Container shell access
121 |
122 | 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 `%%IMAGE%%` container:
123 |
124 | ```console
125 | $ docker exec -it some-%%REPO%% bash
126 | ```
127 |
128 | ## MariaDB-Backup
129 |
130 | As MariaDB-Backup is highly coupled with the server version, it can be useful to use the `mariadb-backup` in the %%REPO%% container of an explicit version:
131 |
132 | ```console
133 | $ docker run --volume /backup-volume:/backup --rm %%REPO%%:10.6.15 mariadb-backup --help
134 | ```
135 |
136 | ## Container viewing MariaDB logs
137 |
138 | The log is available through Docker's container log:
139 |
140 | ```console
141 | $ docker logs some-%%REPO%%
142 | ```
143 |
144 | ## Using a custom MariaDB configuration file
145 |
146 | 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).
147 |
148 | The `%%IMAGE%%` image configuration contains the Ubuntu MariaDB variables with two custom changes for the container:
149 |
150 | [host-cache-size=0](https://mariadb.com/kb/en/server-system-variables/#host_cache_size)
151 | [skip-name-resolve](https://mariadb.com/kb/en/server-system-variables/#skip_name_resolve)
152 |
153 | 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 `%%IMAGE%%`.
154 |
155 | To view the resulting configuration of your `%%IMAGE%%` container:
156 |
157 | ```console
158 | $ docker run --name some-%%REPO%% -v /my/custom:/etc/mysql/conf.d --rm %%IMAGE%%:latest my_print_defaults --mysqld
159 | ```
160 |
161 | ### Configuration without a `cnf` file
162 |
163 | 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:
164 |
165 | ```console
166 | $ docker run --name some-%%REPO%% -e MARIADB_ROOT_PASSWORD=my-secret-pw -d %%IMAGE%%:latest --port 3808
167 | ```
168 |
169 | If you would like to see a complete list of available options, just run:
170 |
171 | ```console
172 | $ docker run -it --rm %%IMAGE%%:latest --verbose --help
173 | ```
174 |
175 | ## Environment Variables
176 |
177 | When you start the `%%IMAGE%%` 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.
178 |
179 | 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.
180 |
181 | 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/).
182 |
183 | ### `MARIADB_AUTO_UPGRADE`
184 |
185 | 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.
186 |
187 | ## Secrets
188 |
189 | 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:
190 |
191 | ```console
192 | $ docker run --name some-mysql -e MARIADB_ROOT_PASSWORD_FILE=/run/secrets/mariadb-root -d %%IMAGE%%:latest
193 | ```
194 |
195 | # Initializing the database contents
196 |
197 | 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 `%%IMAGE%%` 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.
198 |
199 | # Caveats
200 |
201 | ## Where to Store Data
202 |
203 | Important note: There are several ways to store data used by applications that run in Docker containers. We encourage users of the `%%IMAGE%%` images to familiarize themselves with the options available, including:
204 |
205 | - 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.
206 | - 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.
207 |
208 | 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:
209 |
210 | 1. Create a data directory on a suitable volume on your host system, e.g. `/my/own/datadir`.
211 | 2. Start your `%%IMAGE%%` container like this:
212 |
213 | ```console
214 | $ docker run --name some-%%REPO%% -v /my/own/datadir:/var/lib/mysql:Z -e MARIADB_ROOT_PASSWORD=my-secret-pw -d %%IMAGE%%:latest
215 | ```
216 |
217 | 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.
218 |
219 | ## No connections until MariaDB init completes
220 |
221 | 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.
222 |
223 | ## Health/Liveness/Readiness Checking
224 |
225 | 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.
226 |
227 | ## Usage against an existing database
228 |
229 | If you start your `%%IMAGE%%` 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.
230 |
231 | ## Backups and Restores
232 |
233 | 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/).
234 |
235 | ## Frequently Asked Questions / How to reset root and user passwords
236 |
237 | 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).
238 |
239 | ## How to install MariaDB plugins
240 |
241 | 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/).
242 |
243 | # Related Images
244 |
245 | - [MariaDB MaxScale](https://hub.docker.com/r/mariadb/maxscale/tags)
246 | - [MariaDB ColumnStore](https://hub.docker.com/r/mariadb/columnstore/tags)
247 |
248 | # Compose File Examples
249 |
250 | Example compose files using this `%%IMAGE%%` are located in %%GITHUB-REPO%% in the `/examples` folder.
251 |
```