## 1. Project Overview & Quickstart (tianon/test.sh) # test.sh Open-source repository tianon/test.sh ### Repository Details - **Repository:** [tianon/test.sh](https://github.com/tianon/test.sh) - **Primary Language:** Code *Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.* ## 2. Official Technical Reference & Guides (tianon/docs) ## File: README.md # What is this? This repository contains the docs for each of the Docker official images. See [docker-library/official-images](https://github.com/docker-library/official-images) for the configuration how the images are built. To see all of the official images go to the [hub](https://hub.docker.com/explore/). All Markdown files here are run through [tianon's fork of `markdownfmt`](https://github.com/tianon/markdownfmt) (only forked to add some smaller-diff preference and minor DockerHub-compatibility changes), and verified as formatted correctly via Travis-CI. - [Travis CI: ](https://travis-ci.org/docker-library/docs) - [Automated `update.sh` and `push.sh`: ](https://doi-janky.infosiftr.net/job/docs/job/update/) # How do I add a new image's docs - create a folder for my image: `mkdir myimage` - create a `README-short.txt` (required, 100 char max) - create a `content.md` (required) - create a `license.md` (required) - create a `github-repo` (required) - add a `logo.png` (recommended) Optionally: - run `./update.sh myimage` to generate `myimage/README.md` for your review. **Note:** do not actually commit the `README.md` file; it is automatically generated/committed before being uploaded to Docker Hub. - run `./markdownfmt.sh -l myimage` to verify whether format of your markdown files is compliant to `tianon/markdownfmt`. In case you see any file names, markdownfmt detected some issues, which might result in a failed build during continuous integration. run `./markdownfmt.sh -d myimage` to see a diff of changes required to pass. # How do I update an image's docs To update `README.md` for a specific image do not edit `README.md` directly. Please edit `content.md` or another appropriate file within the folder. To see the changes, run `./update.sh myimage` from the repo root, but do not add the `README.md` changes to your pull request. See also `markdownfmt.sh` point [above](#how-do-i-add-a-new-images-docs). # What are all these files? ## `update.sh` This is the main script used to generate the `README.md` files for each image. The generated file is committed along with the files used to generate it (see below on what customizations are available). Accepted arguments are which image(s) you want to update or no arguments to update all of them. ## `generate-repo-stub-readme.sh` This is used to generate a simple `README.md` to put in the image's repo. Argument is the name of the image, like `golang` and it then outputs the readme to standard out. ## `push.pl` This is used by us to push the actual content of the READMEs to the Docker Hub as special access is required to modify the Hub description contents. ## `.template-helpers/generate-dockerfile-links-partial.sh` This script is used by `update.sh` to create the "Supported tags and respective `Dockerfile` links" section of each generated `README.md` from the information in the [official-images `library/` manifests](https://github.com/docker-library/official-images/tree/master/library). ## `.template-helpers/template.md` and `.template-helpers/user-feedback.md` These files are the templates used in building the `/README.md` file, in combination with the individual image's files. ## folder `` This is where all the partial and generated files for a given image reside, (ex: `golang/`). ## `/README.md` This file is generated using `update.sh`. ## `/content.md` This file contains the main content of your image's long description. The basic parts you should have are a "What Is" section and a "How To" section. See the doc on [Official Repos](https://docs.docker.com/docker-hub/official_repos/#a-long-description) for more information on long description. The issues and contribution section is generated by the script but can be overridden. The following is a basic layout: ```markdown # What is XYZ? // about what the contained software is %%LOGO%% # How to use this image // descriptions and examples of common use cases for the image // make use of subsections as necessary ``` ## `/README-short.txt` This is the short description for the docker hub, limited to 100 characters in a single line. > Go (golang) is a general purpose, higher-level, imperative programming language. ## `/logo.png` Logo for the contained software. While there are not hard rules on formatting, most existing logos are square or landscape and stay within a few hundred pixels of width. ## `/license.md` This file should contain a link to the license for the main software in the image. Here is an example for `golang`: ```markdown View [license information](http://golang.org/LICENSE) for the software contained in this image. ``` ## `/github-repo` This file should contain the URL to the GitHub repository for the Dockerfiles that become the images. The file should be in a single line ending in a newline with no extraneous whitespace. Only one GitHub repo per image repository is supported. It is used in generating links. Here is an example for `golang`: ```text https://github.com/docker-library/golang ``` ## `/user-feedback.md` This file is an optional override of the default `user-feedback.md` for those repositories with different issue and contributing policies. # Issues and Contributing If you would like to make a new Official Image, be sure to follow the [guidelines](https://docs.docker.com/docker-hub/official_repos/). Feel free to make a pull request for fixes and improvements to current documentation. For questions or problems on this repo come talk to us via the `#docker-library` IRC channel on [Freenode](https://freenode.net) or open up an issue. --- ## File: aerospike/README.md # Supported tags and respective `Dockerfile` links - [`3.9.1-1`, `latest` (*Dockerfile*)](https://github.com/aerospike/aerospike-server.docker/blob/176a3b8cc79eb883052a8fb1cf3802960b82e600/Dockerfile) For more information about this image and its history, please see [the relevant manifest file (`library/aerospike`)](https://github.com/docker-library/official-images/blob/master/library/aerospike). This image is updated via [pull requests to the `docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images/pulls?q=label%3Alibrary%2Faerospike). For detailed information about the virtual/transfer sizes and individual layers of each of the above supported tags, please see [the `repos/aerospike/tag-details.md` file](https://github.com/docker-library/repo-info/blob/master/repos/aerospike/tag-details.md) in [the `docker-library/repo-info` GitHub repo](https://github.com/docker-library/repo-info). # Aerospike Aerospike is an open source distributed database. Aerospike is built on a "shared nothing" architecture designed to reliably store terabytes of data with automatic fail-over, replication and cross data-center synchronization. Documentation for Aerospike is available at [http://aerospike.com/docs](https://www.aerospike.com/docs). # Using this Image The following will run `asd` with all the exposed ports forwarded to the host machine. ```console $ docker run -d --name aerospike -p 3000:3000 -p 3001:3001 -p 3002:3002 -p 3003:3003 aerospike/aerospike-server ``` **NOTE** Although this is the simplest method to getting Aerospike up and running, but it is not the preferred method. To properly run the container, please specify a **custom configuration** with the **access-address** defined. ## Custom Aerospike Configuration By default, `asd` will use the configuration file at `/etc/aerospike/aerospike.conf`, which is added to the directory by the Dockerfile. To provide a custom configuration, you should first mount a directory containing the custom aerospike.conf file using the `-v` option for `docker`: -v :/opt/aerospike/etc Where `` is the path to a directory containing your custom aerospike.conf file. Next, you will want to tell `asd` to use the configuration file that was just mounted by using the `--config-file` option for `aerospike/aerospike-server`: --config-file /opt/aerospike/etc/aerospike.conf This will tell `asd` to use the config file at `/opt/aerospike/etc/aerospike.conf`, which is mapped from `/aerospike.conf`. A full example: ```console $ docker run -d -v :/opt/aerospike/etc --name aerospike -p 3000:3000 -p 3001:3001 -p 3002:3002 -p 3003:3003 aerospike/aerospike-server asd --foreground --config-file /opt/aerospike/etc/aerospike.conf ``` ### access-address Configuration In order for Aerospike to properly broadcast its address to the cluster or applications, the **access-address** needs to be set in the configuration file. If it is not set, then the IP address within the container will be used, which is not accessible to other nodes. To specify **access-address** in aerospike.conf: network { service { address any # Listening IP Address port 3000 # Listening Port access-address 192.168.1.100 # IP Address to be used by applications and other nodes in the cluster. } ... ## Persistent Data Directory With Docker, the files within the container are not persisted. To persist the data, you will want to mount a directory from the host to the guest's `/opt/aerospike/data` using the `-v` option: -v :/opt/aerospike/data Where `` is the path to a directory containing your data files. A full example: ```console $ docker run -d -v :/opt/aerospike/data --name aerospike -p 3000:3000 -p 3001:3001 -p 3002:3002 -p 3003:3003 aerospike/aerospike-server ``` ## Clustering Aerospike recommends using Mesh Clustering. Mesh uses TCP point to point connections for heartbeats. Each node in the cluster maintains a heartbeat connection to all other nodes. Please see [http://www.aerospike.com/docs/operations/configure/network/heartbeat/#mesh-unicast-heartbeat](http://www.aerospike.com/docs/operations/configure/network/heartbeat/#mesh-unicast-heartbeat) ### Mesh Clustering Mesh networking requires setting up links between each node in the cluster. This can be achieved in two ways: 1. Define a configuration for each node in the cluster, as defined in [Network Heartbeat Configuration](http://www.aerospike.com/docs/operations/configure/network/heartbeat/#mesh-unicast-heartbeat). 2. Use `asinfo` to send the `tip` command, to make the node aware of another node, as defined in [tip command in asinfo](http://www.aerospike.com/docs/tools/asinfo/#tip). For more details and examples of clustering Aerospike in Docker, please see [Deploying Aerospike clusters with Docker](http://www.aerospike.com/docs/deploy_guides/docker/). ## Sending Performance Data to Aerospike Aerospike Telemetry is a feature that allows us to collect certain use data – not the database data – on your Aerospike Community Edition server use. We'd like to know when clusters are created and destroyed, cluster size, cluster workload, how often queries are run, whether instances are deployed purely in-memory or with Flash. Aerospike Telemetry collects information from running Community Edition server instances every 10 minutes. The data helps us to understand how the product is being used, identify issues, and create a better experience for the end user. [More Info](http://www.aerospike.com/aerospike-telemetry/) # License Copyright 2014-2015 Aerospike, Inc. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at [http://www.apache.org/licenses/LICENSE-2.0](http://www.apache.org/licenses/LICENSE-2.0). Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. # Supported Docker versions This image is officially supported on Docker version 1.12.1. Support for older versions (down to 1.6) is provided on a best-effort basis. Please see [the Docker installation documentation](https://docs.docker.com/installation/) for details on how to upgrade your Docker daemon. # User Feedback ## Documentation Documentation for this image is stored in the [`aerospike/` directory](https://github.com/docker-library/docs/tree/master/aerospike) of the [`docker-library/docs` GitHub repo](https://github.com/docker-library/docs). Be sure to familiarize yourself with the [repository's `README.md` file](https://github.com/docker-library/docs/blob/master/README.md) before attempting a pull request. ## Issues If you have any problems with or questions about this image, please contact us on the [Aerospike Forums](https://discuss.aerospike.com) or through a [GitHub issue](https://github.com/aerospike/aerospike-server.docker/issues). If the issue is related to a CVE, please check for [a `cve-tracker` issue on the `official-images` repository first](https://github.com/docker-library/official-images/issues?q=label%3Acve-tracker). You can also reach many of the official image maintainers via the `#docker-library` IRC channel on [Freenode](https://freenode.net). ## Contributing You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can. Before you start to code, we recommend discussing your plans on the [Aerospike Forums](https://discuss.aerospike.com) or through a [GitHub issue](https://github.com/aerospike/aerospike-server.docker/issues), especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing. --- ## File: alpine/README.md # Supported tags and respective `Dockerfile` links - [`3.1` (*versions/library-3.1/Dockerfile*)](https://github.com/gliderlabs/docker-alpine/blob/a9a9643b27e2c3ac5c54aa6652a465795719edf9/versions/library-3.1/Dockerfile) - [`3.2` (*versions/library-3.2/Dockerfile*)](https://github.com/gliderlabs/docker-alpine/blob/322a7330bb18e07a71b648033f5b76e122c064d3/versions/library-3.2/Dockerfile) - [`3.3` (*versions/library-3.3/Dockerfile*)](https://github.com/gliderlabs/docker-alpine/blob/3d320a4b32a6b19c31b4b8b36752138e442031c9/versions/library-3.3/Dockerfile) - [`3.4`, `latest` (*versions/library-3.4/Dockerfile*)](https://github.com/gliderlabs/docker-alpine/blob/8f23fc2e995ab8f7f0f5960c6a1ddd12f57efd0c/versions/library-3.4/Dockerfile) - [`edge` (*versions/library-edge/Dockerfile*)](https://github.com/gliderlabs/docker-alpine/blob/626d0f762c17632c260c7be43a953817bf986c86/versions/library-edge/Dockerfile) For more information about this image and its history, please see [the relevant manifest file (`library/alpine`)](https://github.com/docker-library/official-images/blob/master/library/alpine). This image is updated via [pull requests to the `docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images/pulls?q=label%3Alibrary%2Falpine). For detailed information about the virtual/transfer sizes and individual layers of each of the above supported tags, please see [the `repos/alpine/tag-details.md` file](https://github.com/docker-library/repo-info/blob/master/repos/alpine/tag-details.md) in [the `docker-library/repo-info` GitHub repo](https://github.com/docker-library/repo-info). # What is Alpine Linux? [Alpine Linux](http://alpinelinux.org/) is a Linux distribution built around [musl libc](http://www.musl-libc.org/) and [BusyBox](http://www.busybox.net/). The image is only 5 MB in size and has access to a [package repository](http://forum.alpinelinux.org/packages) that is much more complete than other BusyBox based images. This makes Alpine Linux a great image base for utilities and even production applications. [Read more about Alpine Linux here](https://www.alpinelinux.org/about/) and you can see how their mantra fits in right at home with Docker images. # How to use this image ## Usage Use like you would any other base image: ```dockerfile FROM alpine:3.3 RUN apk add --no-cache mysql-client ENTRYPOINT ["mysql"] ``` This example has a virtual image size of only 16 MB. Compare that to our good friend Ubuntu: ```dockerfile FROM ubuntu:14.04 RUN apt-get update \ && apt-get install -y mysql-client \ && rm -rf /var/lib/apt/lists/* ENTRYPOINT ["mysql"] ``` This yields us a virtual image size of about 232 MB image. ## Documentation This image is well documented. [Check out the documentation at Viewdocs](http://gliderlabs.viewdocs.io/docker-alpine). # Supported Docker versions This image is officially supported on Docker version 1.12.1. Support for older versions (down to 1.6) is provided on a best-effort basis. Please see [the Docker installation documentation](https://docs.docker.com/installation/) for details on how to upgrade your Docker daemon. # User Feedback ## Documentation Documentation for this image is stored in the [`alpine/` directory](https://github.com/docker-library/docs/tree/master/alpine) of the [`docker-library/docs` GitHub repo](https://github.com/docker-library/docs). Be sure to familiarize yourself with the [repository's `README.md` file](https://github.com/docker-library/docs/blob/master/README.md) before attempting a pull request. ## Issues If you have any problems with or questions about this image, please contact us through a [GitHub issue](https://github.com/gliderlabs/docker-alpine/issues). If the issue is related to a CVE, please check for [a `cve-tracker` issue on the `official-images` repository first](https://github.com/docker-library/official-images/issues?q=label%3Acve-tracker). You can also reach many of the official image maintainers via the `#docker-library` IRC channel on [Freenode](https://freenode.net). ## Contributing You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can. Before you start to code, we recommend discussing your plans through a [GitHub issue](https://github.com/gliderlabs/docker-alpine/issues), especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing. --- ## File: arangodb/README.md # Supported tags and respective `Dockerfile` links - [`2.5.5`, `2.5` (*jessie/2.5.5/Dockerfile*)](https://github.com/arangodb/arangodb-docker/blob/636cd874df38edd77a187c08e1803693b3d978d3/jessie/2.5.5/Dockerfile) - [`2.6`, `2.6.10` (*jessie/2.6.10/Dockerfile*)](https://github.com/arangodb/arangodb-docker/blob/803663b157696616d70e2bb44ce6e256f912e3a6/jessie/2.6.10/Dockerfile) - [`2.7`, `2.7.5` (*jessie/2.7.5/Dockerfile*)](https://github.com/arangodb/arangodb-docker/blob/dbfcc5f3edb37f622a2acd221b58106547b05fae/jessie/2.7.5/Dockerfile) - [`2.8`, `2.8.11` (*jessie/2.8.11/Dockerfile*)](https://github.com/arangodb/arangodb-docker/blob/05366cb4c6a6aab8e1ff9ca74c81b09d9a57b5b5/jessie/2.8.11/Dockerfile) - [`3.0`, `3.0.10`, `latest` (*jessie/3.0.10/Dockerfile*)](https://github.com/arangodb/arangodb-docker/blob/b71073b2e36acff7d0660b7f73e659f16facbf99/jessie/3.0.10/Dockerfile) For more information about this image and its history, please see [the relevant manifest file (`library/arangodb`)](https://github.com/docker-library/official-images/blob/master/library/arangodb). This image is updated via [pull requests to the `docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images/pulls?q=label%3Alibrary%2Farangodb). For detailed information about the virtual/transfer sizes and individual layers of each of the above supported tags, please see [the `repos/arangodb/tag-details.md` file](https://github.com/docker-library/repo-info/blob/master/repos/arangodb/tag-details.md) in [the `docker-library/repo-info` GitHub repo](https://github.com/docker-library/repo-info). # What is ArangoDB? ArangoDB is a multi-model, open-source database with flexible data models for documents, graphs, and key-values. Build high performance applications using a convenient SQL-like query language or JavaScript extensions. Use ACID transactions if you require them. Scale horizontally and vertically with a few mouse clicks. The supported data models can be mixed in queries and allow ArangoDB to be the aggregation point for the data request you have in mind. > [arangodb.com](https://arangodb.com) ## Key Features in ArangoDB **Multi-Model** Documents, graphs and key-value pairs — model your data as you see fit for your application. **Joins** Conveniently join what belongs together for flexible ad-hoc querying, less data redundancy. **Transactions** Easy application development keeping your data consistent and safe. No hassle in your client. Joins and Transactions are key features for flexible, secure data designs, widely used in RDBMSs that you won't want to miss in NoSQL products. You decide how and when to use Joins and strong consistency guarantees, keeping all the power for scaling and performance as choice. Furthermore, ArangoDB offers a microservice framework called [Foxx](https://www.arangodb.com/foxx) to build your own Rest API with a few lines of code. #### ArangoDB Documentation - [ArangoDB Documentation](https://www.arangodb.com/documentation) - [ArangoDB Tutorials](https://www.arangodb.com/tutorials) ## How to use this image ### Start an ArangoDB instance In order to start an ArangoDB instance run ```console unix> docker run -e ARANGO_RANDOM_ROOT_PASSWORD=1 -d --name arangodb-instance arangodb ``` Will create and launch the arangodb docker instance as background process. The Identifier of the process is printed. By default ArangoDB listen on port 8529 for request and the image includes `EXPOSE 8529`. If you link an application container it is automatically available in the linked container. See the following examples. In order to get the IP arango listens on run: ```console unix> docker inspect --format '{{ .NetworkSettings.IPAddress }}' arangodb-instance ``` ### Using the instance In order to use the running instance from an application, link the container ```console unix> docker run -e ARANGO_RANDOM_ROOT_PASSWORD=1 --name my-app --link arangodb-instance:db-link arangodb ``` This will use the instance with the name `arangodb-instance` and link it into the application container. The application container will contain environment variables DB_LINK_PORT_8529_TCP=tcp://172.17.0.17:8529 DB_LINK_PORT_8529_TCP_ADDR=172.17.0.17 DB_LINK_PORT_8529_TCP_PORT=8529 DB_LINK_PORT_8529_TCP_PROTO=tcp DB_LINK_NAME=/naughty_ardinghelli/db-link These can be used to access the database. ### Exposing the port to the outside world If you want to expose the port to the outside world, run ```console unix> docker run -e ARANGO_RANDOM_ROOT_PASSWORD=1 -p 8529:8529 -d arangodb ``` ArangoDB listen on port 8529 for request and the image includes `EXPOSE 8529`. The `-p 8529:8529` exposes this port on the host. ### Choosing an authentication method The ArangoDB image provides several authentication methods which can be specified via environment variables (-e) when using `docker run` 1. ARANGO_RANDOM_ROOT_PASSWORD=1 Generate a random root password when starting. The password will be printed to stdout (may be inspected later using `docker logs`) 2. ARANGO_NO_AUTH=1 Disable authentication. Useful for testing. **WARNING** Doing so in production will expose all your data. Make sure that ArangoDB is not diretcly accessible from the internet! 3. ARANGO_ROOT_PASSWORD=somepassword Specify your own root password. ### Command line options In order to get a list of supported options, run ```console unix> docker run -e ARANGO_RANDOM_ROOT_PASSWORD=1 arangodb arangod --help ``` ## Persistent Data ArangoDB use the volume `/var/lib/arangodb3` as database directory to store the collection data and the volume `/var/lib/arangodb3-apps` as apps directory to store any extensions. These directories are marked as docker volumes. Please note that the old version 2.x used `/var/lib/arangodb` and `/var/lib/arangodb-apps`. We will refer to the 3.x variant in this document. In case you are starting a 2.x image just replace it with the 2.x variant. See `docker inspect --format "{{ .Config.Volumes}}" arangodb` for all volumes. A good explanation about persistence and docker container can be found here: [Docker In-depth: Volumes](http://container42.com/2014/11/03/docker-indepth-volumes/), [Why Docker Data Containers are Good](https://medium.com/@ramangupta/why-docker-data-containers-are-good-589b3c6c749e) ### Using host directories You can map the container's volumes to a directory on the host, so that the data is kept between runs of the container. This path `/tmp/arangodb` is in general not the correct place to store you persistent files - it is just an example! ```console unix> mkdir /tmp/arangodb unix> docker -e ARANGO_RANDOM_ROOT_PASSWORD=1 run -p 8529:8529 -d \ -v /tmp/arangodb:/var/lib/arangodb3 \ arangodb ``` This will use the `/tmp/arangodb` directory of the host as database directory for ArangoDB inside the container. ### Using a data container Alternatively you can create a container holding the data. ```console unix> docker create --name arangodb-persist arangodb true ``` And use this data container in your ArangoDB container. ```console unix> docker run -e ARANGO_RANDOM_ROOT_PASSWORD=1 --volumes-from arangodb-persist -p 8529:8529 arangodb ``` If want to save a few bytes you can alternatively use [busybox](https://registry.hub.docker.com/_/busybox) or [alpine](https://registry.hub.docker.com/_/alpine) for creating the volume only containers. Please note that you need to provide the used volumes in this case. For example ```console unix> docker run -d --name arangodb-persist -v /var/lib/arangodb3 busybox true ``` ### Using as a base image If you are using the image as a base image please make sure to wrap any CMD in the [exec](https://docs.docker.com/engine/reference/builder/#cmd) form. Otherwise the default entrypoint will not do its bootstrapping work. # License [Arangodb itself is licensed under the Apache License](https://github.com/arangodb/arangodb/blob/devel/LICENSE), but it contains [software of third parties under their respective licenses](https://github.com/arangodb/arangodb/blob/devel/LICENSES-OTHER-COMPONENTS.md). # Supported Docker versions This image is officially supported on Docker version 1.12.1. Support for older versions (down to 1.6) is provided on a best-effort basis. Please see [the Docker installation documentation](https://docs.docker.com/installation/) for details on how to upgrade your Docker daemon. # User Feedback ## Documentation Documentation for this image is stored in the [`arangodb/` directory](https://github.com/docker-library/docs/tree/master/arangodb) of the [`docker-library/docs` GitHub repo](https://github.com/docker-library/docs). Be sure to familiarize yourself with the [repository's `README.md` file](https://github.com/docker-library/docs/blob/master/README.md) before attempting a pull request. ## Issues If you have any problems with or questions about this image, please contact us through a [GitHub issue](https://github.com/arangodb/arangodb-docker/issues). If the issue is related to a CVE, please check for [a `cve-tracker` issue on the `official-images` repository first](https://github.com/docker-library/official-images/issues?q=label%3Acve-tracker). You can also reach many of the official image maintainers via the `#docker-library` IRC channel on [Freenode](https://freenode.net). ## Contributing You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can. Before you start to code, we recommend discussing your plans through a [GitHub issue](https://github.com/arangodb/arangodb-docker/issues), especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing. --- ## File: backdrop/README.md # Supported tags and respective `Dockerfile` links - [`1.5.0`, `1.5`, `1`, `1.5.0-apache`, `1.5-apache`, `1-apache`, `apache`, `latest` (*1/apache/Dockerfile*)](https://github.com/backdrop-ops/backdrop-docker/blob/204f01a842a77ea6b4f99797b3e7bdc31db05925/1/apache/Dockerfile) - [`1.5.0-fpm`, `1.5-fpm`, `1-fpm`, `fpm` (*1/fpm/Dockerfile*)](https://github.com/backdrop-ops/backdrop-docker/blob/204f01a842a77ea6b4f99797b3e7bdc31db05925/1/fpm/Dockerfile) For more information about this image and its history, please see [the relevant manifest file (`library/backdrop`)](https://github.com/docker-library/official-images/blob/master/library/backdrop). This image is updated via [pull requests to the `docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images/pulls?q=label%3Alibrary%2Fbackdrop). For detailed information about the virtual/transfer sizes and individual layers of each of the above supported tags, please see [the `repos/backdrop/tag-details.md` file](https://github.com/docker-library/repo-info/blob/master/repos/backdrop/tag-details.md) in [the `docker-library/repo-info` GitHub repo](https://github.com/docker-library/repo-info). # What is Backdrop CMS? Backdrop CMS is a comprehensive Content Management System for small to medium sized businesses and non-profits. It is a fork of the Drupal project. Backdrop CMS enables people to build highly customized websites, affordably, through collaboration and open source software. For more on the Backdrop's philosophy see https://backdropcms.org/philosophy. # How to use this image The basic pattern for starting a `backdrop` instance is: ```console $ docker run --name some-backdrop --link some-mysql:mysql -d backdrop ``` The following environment variables are also honored for configuring your Backdrop CMS instance: - `-e BACKDROP_DB_HOST=...` (defaults to the IP and port of the linked `mysql` container) - `-e BACKDROP_DB_USER=...` (defaults to "root") - `-e BACKDROP_DB_PASSWORD=...` (defaults to the value of the `MYSQL_ROOT_PASSWORD` environment variable from the linked `mysql` container) - `-e BACKDROP_DB_NAME=...` (defaults to "backdrop") - `-e BACKDROP_DB_PORT=...` (defaults to 3306) - `-e BACKDROP_DB_DRIVER=...` (defaults to "mysql") The `BACKDROP_DB_NAME` **must already exist** on the given MySQL server. Check out the [official mysql image](https://hub.docker.com/_/mysql/) for more info on spinning up a DB. If you'd like to be able to access the instance from the host without the container's IP, standard port mappings can be used: ```console $ docker run --name some-backdrop --link some-mysql:mysql -p 8080:80 -d backdrop ``` Then, access it via `http://localhost:8080` or `http://host-ip:8080` in a browser. If you'd like to use an external database instead of a linked `mysql` container, specify the hostname and port with `BACKDROP_DB_HOST`/`BACKDROP_DB_PORT` along with the password in `BACKDROP_DB_PASSWORD` and the username in `BACKDROP_DB_USER` (if it is something other than `root`): ```console $ docker run --name some-backdrop \ -e BACKDROP_DB_HOST=10.1.2.3 \ -e BACKDROP_DB_PORT=10432 \ -e BACKDROP_DB_USER=... \ -e BACKDROP_DB_PASSWORD=... \ -d backdrop ``` ## ... via [`docker-compose`](https://github.com/docker/compose) Example `docker-compose.yml` for `backdrop`: ```yaml backdrop: image: backdrop links: - db:mysql ports: - 8080:80 db: image: mysql environment: MYSQL_USER: backdrop MYSQL_PASSWORD: backdrop MYSQL_ALLOW_EMPTY_PASSWORD: 'yes' MYSQL_DATABASE: backdrop ``` Run `docker-compose up`, wait for it to initialize completely, and visit `http://localhost:8080` or `http://host-ip:8080`. ## Adding additional libraries / extensions This image does not provide any additional PHP extensions or other libraries, even if they are required by popular plugins. There are an infinite number of possible plugins, and they potentially require any extension PHP supports. Including every PHP extension that exists would dramatically increase the image size. If you need additional PHP extensions, you'll need to create your own image `FROM` this one. The [documentation of the `php` image](https://github.com/docker-library/docs/blob/master/php/README.md#how-to-install-more-php-extensions) explains how to compile additional extensions. Additionally, the [`drupal:7` Dockerfile](https://github.com/docker-library/drupal/blob/bee08efba505b740a14d68254d6e51af7ab2f3ea/7/Dockerfile#L6-9) has an example of doing this. The following Docker Hub features can help with the task of keeping your dependent images up-to-date: - [Automated Builds](https://docs.docker.com/docker-hub/builds/) let Docker Hub automatically build your Dockerfile each time you push changes to it. - [Repository Links](https://docs.docker.com/docker-hub/builds/#repository-links) can ensure that your image is also rebuilt any time `backdrop` is updated. # License View [license information](https://backdropcms.org/license) for the software contained in this image. # Supported Docker versions This image is officially supported on Docker version 1.12.1. Support for older versions (down to 1.6) is provided on a best-effort basis. Please see [the Docker installation documentation](https://docs.docker.com/installation/) for details on how to upgrade your Docker daemon. # User Feedback ## Documentation Documentation for this image is stored in the [`backdrop/` directory](https://github.com/docker-library/docs/tree/master/backdrop) of the [`docker-library/docs` GitHub repo](https://github.com/docker-library/docs). Be sure to familiarize yourself with the [repository's `README.md` file](https://github.com/docker-library/docs/blob/master/README.md) before attempting a pull request. ## Issues If you have any problems with or questions about this image, please contact us through a [GitHub issue](https://github.com/backdrop-ops/backdrop-docker/issues). If the issue is related to a CVE, please check for [a `cve-tracker` issue on the `official-images` repository first](https://github.com/docker-library/official-images/issues?q=label%3Acve-tracker). You can also reach many of the official image maintainers via the `#docker-library` IRC channel on [Freenode](https://freenode.net). ## Contributing You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can. Before you start to code, we recommend discussing your plans through a [GitHub issue](https://github.com/backdrop-ops/backdrop-docker/issues), especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing. --- ## File: bonita/README.md # Supported tags and respective `Dockerfile` links - [`7.2.4` (*7.2/Dockerfile*)](https://github.com/Bonitasoft-Community/docker_bonita/blob/c8d6cbb007b77a9ce5b22a7e874608962f863e99/7.2/Dockerfile) - [`7.3.2`, `latest` (*7.3/Dockerfile*)](https://github.com/Bonitasoft-Community/docker_bonita/blob/50a2a367f8538ada69e3e17889896d98ff28ca21/7.3/Dockerfile) For more information about this image and its history, please see [the relevant manifest file (`library/bonita`)](https://github.com/docker-library/official-images/blob/master/library/bonita). This image is updated via [pull requests to the `docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images/pulls?q=label%3Alibrary%2Fbonita). For detailed information about the virtual/transfer sizes and individual layers of each of the above supported tags, please see [the `repos/bonita/tag-details.md` file](https://github.com/docker-library/repo-info/blob/master/repos/bonita/tag-details.md) in [the `docker-library/repo-info` GitHub repo](https://github.com/docker-library/repo-info). # What is Bonita BPM? Bonita BPM 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 of the French computer science company Groupe Bull. Since 2009, the development of Bonita is supported by a company dedicated to this activity: Bonitasoft. > [wikipedia.org/wiki/Bonita_BPM](http://en.wikipedia.org/wiki/Bonita_BPM) # How to use this image ## Quick start ```console $ docker run --name bonita -d -p 8080:8080 bonita ``` This will start a container running the [Tomcat Bundle](http://documentation.bonitasoft.com/tomcat-bundle-2) with Bonita BPM Engine + Bonita BPM Portal. With no environment variables specified, it's as like 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 BPM uses a H2 database here. You can access the Bonita BPM Portal on http://localhost:8080/bonita and login using the default credentials: install / install ## Link Bonita BPM to a database ### PostgreSQL PostgreSQL is the recommanded database. [Set max_prepared_transactions to 100](http://documentation.bonitasoft.com/database-configuration-business-data-1): mkdir -p custom_postgres echo '#!/bin/bash' > custom_postgres/bonita.sh echo 'sed -i "s/^.*max_prepared_transactions\s*=\s*\(.*\)$/max_prepared_transactions = 100/" "$PGDATA"/postgresql.conf' >> custom_postgres/bonita.sh chmod +x custom_postgres/bonita.sh Mount that directory location as /docker-entrypoint-initdb.d inside the PostgreSQL container: ```console $ docker run --name mydbpostgres -v "$PWD"/custom_postgres/:/docker-entrypoint-initdb.d -e POSTGRES_PASSWORD=mysecretpassword -d postgres:9.3 ``` See the [official PostgreSQL documentation](https://registry.hub.docker.com/_/postgres/) for more details. ```console $ docker run --name bonita_postgres --link mydbpostgres:postgres -d -p 8080:8080 bonita ``` ### MySQL There are known issues with the management of XA transactions by MySQL engine and driver: see MySQL bugs [17343](http://bugs.mysql.com/bug.php?id=17343) and [12161](http://bugs.mysql.com/bug.php?id=12161) for more details. Thus, using MySQL database in a production environment is not recommended. [Increase the packet size](http://documentation.bonitasoft.com/database-configuration-2#mysqlspec) which is set by default to 1M: mkdir -p custom_mysql echo "[mysqld]" > custom_mysql/bonita.cnf echo "max_allowed_packet=16M" >> custom_mysql/bonita.cnf Mount that directory location as /etc/mysql/conf.d inside the MySQL container: ```console $ docker run --name mydbmysql -v "$PWD"/custom_mysql/:/etc/mysql/conf.d -e MYSQL_ROOT_PASSWORD=mysecretpassword -d mysql:5.5 ``` See the [official MySQL documentation](https://registry.hub.docker.com/_/mysql/) for more details. Start your application container to link it to the MySQL container: ```console $ docker run --name bonita_mysql --link mydbmysql:mysql -d -p 8080:8080 bonita ``` ## Modify default credentials ```console $ docker run --name=bonita -e "TENANT_LOGIN=tech_user" -e "TENANT_PASSWORD=secret" -e "PLATFORM_LOGIN=pfadmin" -e "PLATFORM_PASSWORD=pfsecret" -d -p 8080:8080 bonita ``` Now you can access the Bonita BPM Portal on localhost:8080/bonita and login using: tech_user / secret ## Where to store data Most of the data are stored in a database and can be stored outside the Bonita container as described above using the PostgreSQL or MySQL container. However, some data remains inside the Bonita bundle. Bonita Home is a folder, called `bonita`, which contains configuration, working, and temporary folders and files. There are also log files inside the `logs` folder. Important note: There are several ways to store data used by applications that run in Docker containers. We encourage users of the `bonita` images to familiarize themselves with the options available, including: - Let Docker manage the storage of your data [by writing the files to disk on the host system using its own internal volume management](https://docs.docker.com/userguide/dockervolumes/#adding-a-data-volume). This is the default and is easy and fairly transparent to the user. The downside is that the files may be hard to locate for tools and applications that run directly on the host system, i.e. outside containers. - Create a data directory on the host system (outside the container) and [mount this to a directory visible from inside the container](https://docs.docker.com/userguide/dockervolumes/#mount-a-host-directory-as-a-data-volume). 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 directory permissions and other security mechanisms on the host system are set up correctly. The Docker documentation is a good starting point for understanding the different storage options and variations, and there are multiple blogs and forum postings that discuss and give advice in this area. We will simply show the basic procedure here for the latter option above: 1. Create a data directory on a suitable volume on your host system, e.g. `/my/own/datadir`. 2. Start your `bonita` container like this: docker run --name some-bonita -v /my/own/datadir:/opt/bonita -d bonita:tag The `-v /my/own/datadir:/opt/bonita` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/opt/bonita` inside the container, where Bonita will deploy the bundle and write data files by default. Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to the new data directory so that the container will be allowed to access it: ```console $ chcon -Rt svirt_sandbox_file_t /my/own/datadir ``` ## Migrate from an earlier version of Bonita BPM - Stop the container to perform a backup ```console $ docker stop bonita_7.2.3_postgres ``` - For containers < 7.3.0 : - Check where your data are stored ```console $ docker inspect bonita_7.2.3_postgres [...] "Mounts": [ { "Source": "/home/user/Documents/Docker/Volumes/bonita_7.2.3_postgres", "Destination": "/opt/bonita", "Mode": "", "RW": true } ], [...] ``` - Copy data from the filesystem cp -r bonita_7.2.3_postgres bonita_migration - Retrieve the DB container IP ```console $ docker inspect --format '{{ .NetworkSettings.IPAddress }}' mydbpostgres 172.17.0.26 ``` - Dump the database export PGPASSWORD=mysecretpassword pg_dump -O -x -h 172.17.0.26 -U postgres bonitadb > /tmp/bonitadb.sql Note that businessdb won't be updated with the migration tool but you may want to also backup/move it. - Load the dump export PGPASSWORD=mysecretpassword psql -U postgres -h 172.17.0.26 -d postgres -c "CREATE USER newbonitauser WITH PASSWORD 'newbonitapass';" psql -U postgres -h 172.17.0.26 -d postgres -c "CREATE DATABASE newbonitadb OWNER newbonitauser;" export PGPASSWORD=newbonitapass cat /tmp/bonitadb.sql | psql -U newbonitauser -h 172.17.0.26 newbonitadb - Retrieve the last migration tool - If you migrate to a version < 7.3.0 - get also the target version of the Bonita bundle ```console cd bonita_migration wget http://download.forge.ow2.org/bonita/bonita-migration-distrib-2.15.0.zip wget http://download.forge.ow2.org/bonita/BonitaBPMCommunity-7.2.4-Tomcat-7.0.67.zip unzip bonita-migration-distrib-2.15.0.zip unzip BonitaBPMCommunity-7.2.4-Tomcat-7.0.67.zip ``` - Move the previous Home into the new bundle ```console mv BonitaBPMCommunity-7.2.4-Tomcat-7.0.67/bonita/ BonitaBPMCommunity-7.2.4-Tomcat-7.0.67/bonita.orig cp -r BonitaBPMCommunity-7.2.3-Tomcat-7.0.67/bonita/ BonitaBPMCommunity-7.2.4-Tomcat-7.0.67/bonita/ ``` - If you migrate to a version >= 7.3.0 ```console cd bonita_migration wget http://download.forge.ow2.org/bonita/bonita-migration-distrib-2.15.0.zip unzip bonita-migration-distrib-2.15.0.zip ``` - Configure the migration tool cd bonita-migration-distrib-2.15.0 edit the migration tool config to point towards the copy of bonita home and db vim Config.properties For example : db.vendor=postgres db.url=jdbc:postgresql://172.17.0.26:5432/newbonitadb db.driverClass=org.postgresql.Driver db.user=newbonitauser db.password=newbonitapass # location of the bonita home (only useful when migration from version before 7.3.0) bonita.home=/home/user/Documents/Docker/Volumes/bonita_migration/BonitaBPMCommunity-7.2.3-Tomcat-7.0.67/bonita - Launch the migration cd bin ./bonita-migration-distrib - Launch the new container pointing towards the copy of DB and filesystem - If < 7.3.0 ```console $ docker run --name=bonita_7.2.4_postgres --link mydbpostgres:postgres -e "DB_NAME=newbonitadb" -e "DB_USER=newbonitauser" -e "DB_PASS=newbonitapass" -v "$PWD"/bonita_migration:/opt/bonita/ -d -p 8081:8080 bonita:7.2.4 ``` - If >= 7.3.0 ```console $ docker run --name=bonita_7.3.0_postgres --link mydbpostgres:postgres -e "DB_NAME=newbonitadb" -e "DB_USER=newbonitauser" -e "DB_PASS=newbonitapass" -d -p 8081:8080 bonita:7.3.0 ``` - Reapply specific configuration if needed, for example with a version >= 7.3.0 : ```console $ docker exec -ti bonita_7.3.0_postgres /bin/bash ``` ```console $ cd /opt/bonita/BonitaBPMCommunity-7.3.0-Tomcat-7.0.67/setup $ ./setup.sh pull $ TENANT_LOGIN=tech_user $ TENANT_PASSWORD=secret $ PLATFORM_LOGIN=pfadmin $ PLATFORM_PASSWORD=pfsecret $ sed -e 's/^#userName\s*=.*/'"userName=${TENANT_LOGIN}"'/' \ -e 's/^#userPassword\s*=.*/'"userPassword=${TENANT_PASSWORD}"'/' \ -i platform_conf/current/tenants/1/tenant_engine/bonita-tenant-community-custom.properties $ sed -e 's/^platform.tenant.default.username\s*=.*/'"platform.tenant.default.username=${TENANT_LOGIN}"'/' \ -e 's/^platform.tenant.default.password\s*=.*/'"platform.tenant.default.password=${TENANT_PASSWORD}"'/' \ -i platform_conf/current/platform_portal/platform-tenant-config.properties $ sed -e 's/^#platformAdminUsername\s*=.*/'"platformAdminUsername=${PLATFORM_LOGIN}"'/' \ -e 's/^#platformAdminPassword\s*=.*/'"platformAdminPassword=${PLATFORM_PASSWORD}"'/' \ -i platform_conf/current/platform_engine/bonita-platform-community-custom.properties $ sed -i -e 's/^#GET|/GET|/' -e 's/^#POST|/POST|/' -e 's/^#PUT|/PUT|/' -e 's/^#DELETE|/DELETE|/' -i platform_conf/current/tenants/1/tenant_portal/dynamic-permissions-checks.properties $ ./setup.sh push ``` ```console $ docker restart bonita_7.3.0_postgres ``` For more details regarding Bonita migration, see the [documentation](http://documentation.bonitasoft.com/migrate-earlier-version-bonita-bpm-0). ## Security This Docker image activates both static and dynamic authorization checks by default on REST API. To be consistent, it also deactivates the HTTP API. - REST API authorization - [Static authorization checking](http://documentation.bonitasoft.com/rest-api-authorization-0#static) - [Dynamic authorization checking](http://documentation.bonitasoft.com/rest-api-authorization-0#dynamic) - [HTTP API](http://documentation.bonitasoft.com/rest-api-authorization-0#activate) For specific needs you can override this behavior by setting HTTP_API to true and REST_API_DYN_AUTH_CHECKS to false: ```console $ docker run -e HTTP_API=true -e REST_API_DYN_AUTH_CHECKS=false --name bonita -d -p 8080:8080 bonita ``` ## Environment variables 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. ### `PLATFORM_PASSWORD` This environment variable [is recommended](http://documentation.bonitasoft.com/first-steps-after-setup-1#reset_pw) 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. ### `PLATFORM_LOGIN` 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 user `platformAdmin` will be used. ### `TENANT_PASSWORD` This environment variable [is recommended](http://documentation.bonitasoft.com/first-steps-after-setup-1#reset_pw) 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. ### `TENANT_LOGIN` This optional environment variable is used in conjunction with `TENANT_PASSWORD` to define the username for the tenant administrator. If it is not specified, the default user of `install` will be used. ### `REST_API_DYN_AUTH_CHECKS` This optional environment variable is used to enable/disable [dynamic authorization checking](http://documentation.bonitasoft.com/rest-api-authorization-0#dynamic) on Bonita REST API. The default value is `true`, which will activate dynamic authorization checking. ### `HTTP_API` This optional environment variable is used to enable/disable the Bonita HTTP API. The default value is `false`, which will deactivate the HTTP API. ### `JAVA_OPTS` This optional environment variable is used to customize JAVA_OPTS. The default value is `-Xms1024m -Xmx1024m -XX:MaxPermSize=256m`. ### `ENSURE_DB_CHECK_AND_CREATION` This optional environment variable is used to allow/disallow the SQL queries to automatically check and create the databases using the database administrator credentials. The default value is `true`. ### `DB_VENDOR` 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. ### `DB_HOST`, `DB_PORT` 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. ### `DB_NAME`, `DB_USER`, `DB_PASS` These variables are used in conjunction to create a new user, set that user's password, and create the `bonita` database. `DB_NAME` default value is `bonitadb`. `DB_USER` default value is `bonitauser`. `DB_PASS` default value is `bonitapass`. ### `BIZ_DB_NAME`, `BIZ_DB_USER`, `BIZ_DB_PASS` These variables are used in conjunction to create a new user, set that user's password and create the `bonita` [business database](http://documentation.bonitasoft.com/business-data-model#bdmanddb). `BIZ_DB_NAME` default value is `businessdb`. `BIZ_DB_USER` default value is `businessuser`. `BIZ_DB_PASS` default value is `businesspass`. ### `DB_ADMIN_USER`, `DB_ADMIN_PASS` These variables are optional, and used in conjunction to create users and databases through the administrator account used on the database instance. `DB_ADMIN_USER` if no value is provided, this is automatically set to `root` with MySQL or `postgres` with PostgreSQL. `DB_ADMIN_PASS` if no value is provided, this is automatically set using the value from the linked container: `MYSQL_ENV_MYSQL_ROOT_PASSWORD` or `POSTGRES_ENV_POSTGRES_PASSWORD`. # How to extend this image If you would like to do additional initialization, you can add a `*.sh` script under `/opt/custom-init.d`. The `startup.sh` file will source any `*.sh` script found in this directory to do further initialization before starting the service. For example, you can increase the log level : mkdir -p custom_bonita echo '#!/bin/bash' > custom_bonita/bonita.sh echo 'sed -i "s/^org.bonitasoft.level = WARNING$/org.bonitasoft.level = FINEST/" /opt/bonita/BonitaBPMCommunity-7.0.0-Tomcat-7.0.55/conf/logging.properties' >> custom_bonita/bonita.sh chmod +x custom_bonita/bonita.sh docker run --name bonita_custom -v "$PWD"/custom_bonita/:/opt/custom-init.d -d -p 8080:8080 bonita Note: There are several ways to check the `bonita` logs. One of them is ```console $ docker exec -ti bonita_custom /bin/bash tail -f /opt/bonita/BonitaBPMCommunity-7.0.0-Tomcat-7.0.55/logs/bonita.`date +%Y-%m-%d`.log ``` # License Bonita BPM image includes two parts : - Bonita BPM Engine under [LGPL v2.1](https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html) - Bonita BPM Portal under [GPL v2.0](http://www.gnu.org/licenses/old-licenses/gpl-2.0.html) # Supported Docker versions This image is officially supported on Docker version 1.12.1. Support for older versions (down to 1.6) is provided on a best-effort basis. Please see [the Docker installation documentation](https://docs.docker.com/installation/) for details on how to upgrade your Docker daemon. # User Feedback ## Documentation Documentation for this image is stored in the [`bonita/` directory](https://github.com/docker-library/docs/tree/master/bonita) of the [`docker-library/docs` GitHub repo](https://github.com/docker-library/docs). Be sure to familiarize yourself with the [repository's `README.md` file](https://github.com/docker-library/docs/blob/master/README.md) before attempting a pull request. ## Issues If you have any problems with or questions about this image, please contact us through a [GitHub issue](https://github.com/Bonitasoft-Community/docker_bonita/issues). If the issue is related to a CVE, please check for [a `cve-tracker` issue on the `official-images` repository first](https://github.com/docker-library/official-images/issues?q=label%3Acve-tracker). You can also reach many of the official image maintainers via the `#docker-library` IRC channel on [Freenode](https://freenode.net). ## Contributing You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can. Before you start to code, we recommend discussing your plans through a [GitHub issue](https://github.com/Bonitasoft-Community/docker_bonita/issues), especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing. --- ## File: buildpack-deps/README.md # Supported tags and respective `Dockerfile` links - [`jessie-curl`, `curl` (*jessie/curl/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/a0a59c61102e8b079d568db69368fb89421f75f2/jessie/curl/Dockerfile) - [`jessie-scm`, `scm` (*jessie/scm/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/1845b3f918f69b4c97912b0d4d68a5658458e84f/jessie/scm/Dockerfile) - [`jessie`, `latest` (*jessie/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/f1d33d5c92e1bd2aee9f2333ceb316251e6388d4/jessie/Dockerfile) - [`precise-curl` (*precise/curl/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/af914a5bde2a749884177393c8140384048dc5f9/precise/curl/Dockerfile) - [`precise-scm` (*precise/scm/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/1845b3f918f69b4c97912b0d4d68a5658458e84f/precise/scm/Dockerfile) - [`precise` (*precise/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/f1d33d5c92e1bd2aee9f2333ceb316251e6388d4/precise/Dockerfile) - [`sid-curl` (*sid/curl/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/a0a59c61102e8b079d568db69368fb89421f75f2/sid/curl/Dockerfile) - [`sid-scm` (*sid/scm/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/1845b3f918f69b4c97912b0d4d68a5658458e84f/sid/scm/Dockerfile) - [`sid` (*sid/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/f1d33d5c92e1bd2aee9f2333ceb316251e6388d4/sid/Dockerfile) - [`stretch-curl` (*stretch/curl/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/c7478e564dd5dc063cdb0231764379a6916fe525/stretch/curl/Dockerfile) - [`stretch-scm` (*stretch/scm/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/1845b3f918f69b4c97912b0d4d68a5658458e84f/stretch/scm/Dockerfile) - [`stretch` (*stretch/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/f1d33d5c92e1bd2aee9f2333ceb316251e6388d4/stretch/Dockerfile) - [`trusty-curl` (*trusty/curl/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/af914a5bde2a749884177393c8140384048dc5f9/trusty/curl/Dockerfile) - [`trusty-scm` (*trusty/scm/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/1845b3f918f69b4c97912b0d4d68a5658458e84f/trusty/scm/Dockerfile) - [`trusty` (*trusty/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/f1d33d5c92e1bd2aee9f2333ceb316251e6388d4/trusty/Dockerfile) - [`wheezy-curl` (*wheezy/curl/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/a0a59c61102e8b079d568db69368fb89421f75f2/wheezy/curl/Dockerfile) - [`wheezy-scm` (*wheezy/scm/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/1845b3f918f69b4c97912b0d4d68a5658458e84f/wheezy/scm/Dockerfile) - [`wheezy` (*wheezy/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/f1d33d5c92e1bd2aee9f2333ceb316251e6388d4/wheezy/Dockerfile) - [`xenial-curl` (*xenial/curl/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/2da658b9a1b91fa61d63ffad2ea52685cac6c702/xenial/curl/Dockerfile) - [`xenial-scm` (*xenial/scm/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/2da658b9a1b91fa61d63ffad2ea52685cac6c702/xenial/scm/Dockerfile) - [`xenial` (*xenial/Dockerfile*)](https://github.com/docker-library/buildpack-deps/blob/f1d33d5c92e1bd2aee9f2333ceb316251e6388d4/xenial/Dockerfile) For more information about this image and its history, please see [the relevant manifest file (`library/buildpack-deps`)](https://github.com/docker-library/official-images/blob/master/library/buildpack-deps). This image is updated via [pull requests to the `docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images/pulls?q=label%3Alibrary%2Fbuildpack-deps). For detailed information about the virtual/transfer sizes and individual layers of each of the above supported tags, please see [the `repos/buildpack-deps/tag-details.md` file](https://github.com/docker-library/repo-info/blob/master/repos/buildpack-deps/tag-details.md) in [the `docker-library/repo-info` GitHub repo](https://github.com/docker-library/repo-info). # What is `buildpack-deps`? In spirit, `buildpack-deps` is similar to [Heroku's stack images](https://github.com/heroku/stack-images/blob/master/bin/cedar.sh). It includes a large number of "development header" packages needed by various things like Ruby Gems, PyPI modules, etc. For example, `buildpack-deps` would let you do a `bundle install` in an arbitrary application directory without knowing beforehand that `ssl.h` is required to build a dependent module. # How to use this image This stack is designed to be the foundation of a language-stack image. ## What's included? The main tags of this image are the full batteries-included approach. With them, a majority of arbitrary `gem install` / `npm install` / `pip install` should be successfull without additional header/development packages. For some language stacks, that doesn't make sense, particularly if linking to arbitrary external C libraries is much less common (as in Go and Java, for example), which is where these other smaller variants can come in handy. ### `curl` This variant includes just the `curl`, `wget`, and `ca-certificates` packages. This is perfect for cases like the Java JRE, where downloading JARs is very common and necessary, but checking out code isn't. ### `scm` This variant is based on `curl`, but also adds various source control management tools. As of this writing, the current list of included tools is `bzr`, `git`, `hg`, and `svn`. Intentionally missing is `cvs` due to the dwindling relevance it has (sorry CVS). This image is perfect for cases like the Java JDK, where downloading JARs is very common (hence the `curl` base still), but checking out code also becomes more common as well (compared to the JRE). # License View [license information](https://www.debian.org/social_contract#guidelines) for the software contained in this image. # Supported Docker versions This image is officially supported on Docker version 1.12.1. Support for older versions (down to 1.6) is provided on a best-effort basis. Please see [the Docker installation documentation](https://docs.docker.com/installation/) for details on how to upgrade your Docker daemon. # User Feedback ## Documentation Documentation for this image is stored in the [`buildpack-deps/` directory](https://github.com/docker-library/docs/tree/master/buildpack-deps) of the [`docker-library/docs` GitHub repo](https://github.com/docker-library/docs). Be sure to familiarize yourself with the [repository's `README.md` file](https://github.com/docker-library/docs/blob/master/README.md) before attempting a pull request. ## Issues If you have any problems with or questions about this image, please contact us through a [GitHub issue](https://github.com/docker-library/buildpack-deps/issues). If the issue is related to a CVE, please check for [a `cve-tracker` issue on the `official-images` repository first](https://github.com/docker-library/official-images/issues?q=label%3Acve-tracker). You can also reach many of the official image maintainers via the `#docker-library` IRC channel on [Freenode](https://freenode.net). ## Contributing You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can. Before you start to code, we recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/buildpack-deps/issues), especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing. --- ## File: busybox/README.md # Supported tags and respective `Dockerfile` links - [`1.25.0-glibc`, `1.25-glibc`, `1-glibc`, `glibc` (*glibc/Dockerfile*)](https://github.com/docker-library/busybox/blob/a0558a9006ce0dd6f6ec5d56cfd3f32ebeeb815f/glibc/Dockerfile) - [`1.25.0-musl`, `1.25-musl`, `1-musl`, `musl` (*musl/Dockerfile*)](https://github.com/docker-library/busybox/blob/a0558a9006ce0dd6f6ec5d56cfd3f32ebeeb815f/musl/Dockerfile) - [`1.25.0-uclibc`, `1.25-uclibc`, `1-uclibc`, `uclibc`, `1.25.0`, `1.25`, `1`, `latest` (*uclibc/Dockerfile*)](https://github.com/docker-library/busybox/blob/a0558a9006ce0dd6f6ec5d56cfd3f32ebeeb815f/uclibc/Dockerfile) For more information about this image and its history, please see [the relevant manifest file (`library/busybox`)](https://github.com/docker-library/official-images/blob/master/library/busybox). This image is updated via [pull requests to the `docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images/pulls?q=label%3Alibrary%2Fbusybox). For detailed information about the virtual/transfer sizes and individual layers of each of the above supported tags, please see [the `repos/busybox/tag-details.md` file](https://github.com/docker-library/repo-info/blob/master/repos/busybox/tag-details.md) in [the `docker-library/repo-info` GitHub repo](https://github.com/docker-library/repo-info). # What is BusyBox? The Swiss Army Knife of Embedded Linux Coming in somewhere between 1 and 5 Mb in on-disk size (depending on the variant), [BusyBox](http://www.busybox.net/) is a very good ingredient to craft space-efficient distributions. BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system. > [wikipedia.org/wiki/BusyBox](https://en.wikipedia.org/wiki/BusyBox) # How to use this image ## Run BusyBox shell ```console $ docker run -it --rm busybox ``` This will drop you into an `sh` shell to allow you to do what you want inside a BusyBox system. ## Create a `Dockerfile` for a binary ```dockerfile FROM busybox COPY ./my-static-binary /my-static-binary CMD ["/my-static-binary"] ``` This `Dockerfile` will allow you to create a minimal image for your statically compiled binary. You will have to compile the binary in some other place like another container. For a simpler alternative that's similarly tiny but easier to extend, [see `alpine`](https://hub.docker.com/_/alpine/). ## Image Variants This image contains BusyBox built against various "libc" variants (for a comparison of "libc" variants, [Eta Labs has a very nice chart](http://www.etalabs.net/compare_libcs.html) which lists many similarities and differences). - `busybox:glibc`: [glibc from Debian](https://packages.debian.org/jessie/libc6) (which is then included in the image) - `busybox:musl`: [musl from Alpine](https://pkgs.alpinelinux.org/package/main/x86_64/musl) (statically compiled) - `busybox:uclibc`: [uClibc](https://uclibc.org) via [Buildroot](https://buildroot.org) (statically compiled) For more information about the specific particulars of the build process for each variant, see `Dockerfile.builder` in the same directory as each variant's `Dockerfile` (see links above). # License View [license information](http://www.busybox.net/license.html) for the software contained in this image. # Supported Docker versions This image is officially supported on Docker version 1.12.1. Support for older versions (down to 1.6) is provided on a best-effort basis. Please see [the Docker installation documentation](https://docs.docker.com/installation/) for details on how to upgrade your Docker daemon. # User Feedback ## Documentation Documentation for this image is stored in the [`busybox/` directory](https://github.com/docker-library/docs/tree/master/busybox) of the [`docker-library/docs` GitHub repo](https://github.com/docker-library/docs). Be sure to familiarize yourself with the [repository's `README.md` file](https://github.com/docker-library/docs/blob/master/README.md) before attempting a pull request. ## Issues If you have any problems with or questions about this image, please contact us through a [GitHub issue](https://github.com/docker-library/busybox/issues). If the issue is related to a CVE, please check for [a `cve-tracker` issue on the `official-images` repository first](https://github.com/docker-library/official-images/issues?q=label%3Acve-tracker). You can also reach many of the official image maintainers via the `#docker-library` IRC channel on [Freenode](https://freenode.net). ## Contributing You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can. Before you start to code, we recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/busybox/issues), especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing. --- ## File: cassandra/README.md # Supported tags and respective `Dockerfile` links - [`2.1.15`, `2.1` (*2.1/Dockerfile*)](https://github.com/docker-library/cassandra/blob/ef57ef961003e27469b86178f0b4d184bb64d82e/2.1/Dockerfile) - [`2.2.8`, `2.2`, `2` (*2.2/Dockerfile*)](https://github.com/docker-library/cassandra/blob/ef57ef961003e27469b86178f0b4d184bb64d82e/2.2/Dockerfile) - [`3.0.9`, `3.0` (*3.0/Dockerfile*)](https://github.com/docker-library/cassandra/blob/ef57ef961003e27469b86178f0b4d184bb64d82e/3.0/Dockerfile) - [`3.7`, `3`, `latest` (*3.7/Dockerfile*)](https://github.com/docker-library/cassandra/blob/ef57ef961003e27469b86178f0b4d184bb64d82e/3.7/Dockerfile) For more information about this image and its history, please see [the relevant manifest file (`library/cassandra`)](https://github.com/docker-library/official-images/blob/master/library/cassandra). This image is updated via [pull requests to the `docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images/pulls?q=label%3Alibrary%2Fcassandra). For detailed information about the virtual/transfer sizes and individual layers of each of the above supported tags, please see [the `repos/cassandra/tag-details.md` file](https://github.com/docker-library/repo-info/blob/master/repos/cassandra/tag-details.md) in [the `docker-library/repo-info` GitHub repo](https://github.com/docker-library/repo-info). # What is Cassandra? Apache Cassandra is an open source distributed database management system designed to handle large amounts of data across many commodity servers, providing high availability with no single point of failure. Cassandra offers robust support for clusters spanning multiple datacenters, with asynchronous masterless replication allowing low latency operations for all clients. > [wikipedia.org/wiki/Apache_Cassandra](https://en.wikipedia.org/wiki/Apache_Cassandra) # How to use this image ## Start a `cassandra` server instance Starting a Cassandra instance is simple: ```console $ docker run --name some-cassandra -d cassandra:tag ``` ... where `some-cassandra` is the name you want to assign to your container and `tag` is the tag specifying the Cassandra version you want. See the list above for relevant tags. ## Connect to Cassandra from an application in another Docker container This image exposes the standard Cassandra ports (see the [Cassandra FAQ](https://wiki.apache.org/cassandra/FAQ#ports)), so container linking makes the Cassandra instance available to other application containers. Start your application container like this in order to link it to the Cassandra container: ```console $ docker run --name some-app --link some-cassandra:cassandra -d app-that-uses-cassandra ``` ## Make a cluster Using the environment variables documented below, there are two cluster scenarios: instances on the same machine and instances on separate machines. For the same machine, start the instance as described above. To start other instances, just tell each new node where the first is. ```console $ docker run --name some-cassandra2 -d -e CASSANDRA_SEEDS="$(docker inspect --format='{{ .NetworkSettings.IPAddress }}' some-cassandra)" cassandra:tag ``` ... where `some-cassandra` is the name of your original Cassandra Server container, taking advantage of `docker inspect` to get the IP address of the other container. Or you may use the docker run --link option to tell the new node where the first is: ```console $ docker run --name some-cassandra2 -d --link some-cassandra:cassandra cassandra:tag ``` For separate machines (ie, two VMs on a cloud provider), you need to tell Cassandra what IP address to advertise to the other nodes (since the address of the container is behind the docker bridge). Assuming the first machine's IP address is `10.42.42.42` and the second's is `10.43.43.43`, start the first with exposed gossip port: ```console $ docker run --name some-cassandra -d -e CASSANDRA_BROADCAST_ADDRESS=10.42.42.42 -p 7000:7000 cassandra:tag ``` Then start a Cassandra container on the second machine, with the exposed gossip port and seed pointing to the first machine: ```console $ docker run --name some-cassandra -d -e CASSANDRA_BROADCAST_ADDRESS=10.43.43.43 -p 7000:7000 -e CASSANDRA_SEEDS=10.42.42.42 cassandra:tag ``` ## Connect to Cassandra from `cqlsh` The following command starts another Cassandra container instance and runs `cqlsh` (Cassandra Query Language Shell) against your original Cassandra container, allowing you to execute CQL statements against your database instance: ```console $ docker run -it --link some-cassandra:cassandra --rm cassandra sh -c 'exec cqlsh "$CASSANDRA_PORT_9042_TCP_ADDR"' ``` ... or (simplified to take advantage of the `/etc/hosts` entry Docker adds for linked containers): ```console $ docker run -it --link some-cassandra:cassandra --rm cassandra cqlsh cassandra ``` ... where `some-cassandra` is the name of your original Cassandra Server container. More information about the CQL can be found in the [Cassandra documentation](https://cassandra.apache.org/doc/cql3/CQL.html). ## Container shell access and viewing Cassandra logs 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 `cassandra` container: ```console $ docker exec -it some-cassandra bash ``` The Cassandra Server log is available through Docker's container log: ```console $ docker logs some-cassandra ``` ## Environment Variables When you start the `cassandra` image, you can adjust the configuration of the Cassandra instance by passing one or more environment variables on the `docker run` command line. ### `CASSANDRA_LISTEN_ADDRESS` This variable is for controlling which IP address to listen for incoming connections on. The default value is `auto`, which will set the [`listen_address`](http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html?scroll=configCassandra_yaml__listen_address) option in `cassandra.yaml` to the IP address of the container as it starts. This default should work in most use cases. ### `CASSANDRA_BROADCAST_ADDRESS` This variable is for controlling which IP address to advertise to other nodes. The default value is the value of `CASSANDRA_LISTEN_ADDRESS`. It will set the [`broadcast_address`](http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html?scroll=configCassandra_yaml__broadcast_address) and [`broadcast_rpc_address`](http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html?scroll=configCassandra_yaml__broadcast_rpc_address) options in `cassandra.yaml`. ### `CASSANDRA_RPC_ADDRESS` This variable is for controlling which address to bind the thrift rpc server to. If you do not specify an address, the wildcard address (`0.0.0.0`) will be used. It will set the [`rpc_address`](http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html?scroll=configCassandra_yaml__rpc_address) option in `cassandra.yaml`. ### `CASSANDRA_START_RPC` This variable is for controlling if the thrift rpc server is started. It will set the [`start_rpc`](http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html?scroll=configCassandra_yaml__start_rpc) option in `cassandra.yaml`. ### `CASSANDRA_SEEDS` This variable is the comma-separated list of IP addresses used by gossip for bootstrapping new nodes joining a cluster. It will set the `seeds` value of the [`seed_provider`](http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html?scroll=configCassandra_yaml__seed_provider) option in `cassandra.yaml`. The `CASSANDRA_BROADCAST_ADDRESS` will be added the the seeds passed in so that the sever will talk to itself as well. ### `CASSANDRA_CLUSTER_NAME` This variable sets the name of the cluster and must be the same for all nodes in the cluster. It will set the [`cluster_name`](http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html?scroll=configCassandra_yaml__cluster_name) option of `cassandra.yaml`. ### `CASSANDRA_NUM_TOKENS` This variable sets number of tokens for this node. It will set the [`num_tokens`](http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html?scroll=configCassandra_yaml__num_tokens) option of `cassandra.yaml`. ### `CASSANDRA_DC` This variable sets the datacenter name of this node. It will set the [`dc`](http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/archsnitchGossipPF.html) option of `cassandra-rackdc.properties`. ### `CASSANDRA_RACK` This variable sets the rack name of this node. It will set the [`rack`](http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/archsnitchGossipPF.html) option of `cassandra-rackdc.properties`. ### `CASSANDRA_ENDPOINT_SNITCH` This variable sets the snitch implementation this node will use. It will set the [`endpoint_snitch`](http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html?scroll=configCassandra_yaml__endpoint_snitch) option of `cassandra.yml`. # Caveats ## Where to Store Data Important note: There are several ways to store data used by applications that run in Docker containers. We encourage users of the `cassandra` images to familiarize themselves with the options available, including: - 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/userguide/dockervolumes/#adding-a-data-volume). This is the default and is easy and fairly transparent to the user. The downside is that the files may be hard to locate for tools and applications that run directly on the host system, i.e. outside containers. - Create a data directory on the host system (outside the container) and [mount this to a directory visible from inside the container](https://docs.docker.com/userguide/dockervolumes/#mount-a-host-directory-as-a-data-volume). This places the database files in a known location on the host system, and makes it easy for tools and applications on the host system to access the files. The downside is that the user needs to make sure that the directory exists, and that e.g. directory permissions and other security mechanisms on the host system are set up correctly. The Docker documentation is a good starting point for understanding the different storage options and variations, and there are multiple blogs and forum postings that discuss and give advice in this area. We will simply show the basic procedure here for the latter option above: 1. Create a data directory on a suitable volume on your host system, e.g. `/my/own/datadir`. 2. Start your `cassandra` container like this: ```console $ docker run --name some-cassandra -v /my/own/datadir:/var/lib/cassandra -d cassandra:tag ``` The `-v /my/own/datadir:/var/lib/cassandra` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/var/lib/cassandra` inside the container, where Cassandra by default will write its data files. Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to the new data directory so that the container will be allowed to access it: ```console $ chcon -Rt svirt_sandbox_file_t /my/own/datadir ``` ## No connections until Cassandra init completes If there is no database initialized when the container starts, then a default database will be created. While this is the expected behavior, this means that it will not accept incoming connections until such initialization completes. This may cause issues when using automation tools, such as `docker-compose`, which start several containers simultaneously. # Supported Docker versions This image is officially supported on Docker version 1.12.1. Support for older versions (down to 1.6) is provided on a best-effort basis. Please see [the Docker installation documentation](https://docs.docker.com/installation/) for details on how to upgrade your Docker daemon. # User Feedback ## Documentation Documentation for this image is stored in the [`cassandra/` directory](https://github.com/docker-library/docs/tree/master/cassandra) of the [`docker-library/docs` GitHub repo](https://github.com/docker-library/docs). Be sure to familiarize yourself with the [repository's `README.md` file](https://github.com/docker-library/docs/blob/master/README.md) before attempting a pull request. ## Issues If you have any problems with or questions about this image, please contact us through a [GitHub issue](https://github.com/docker-library/cassandra/issues). If the issue is related to a CVE, please check for [a `cve-tracker` issue on the `official-images` repository first](https://github.com/docker-library/official-images/issues?q=label%3Acve-tracker). You can also reach many of the official image maintainers via the `#docker-library` IRC channel on [Freenode](https://freenode.net). ## Contributing You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can. Before you start to code, we recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/cassandra/issues), especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing. --- ## File: celery/README.md # Supported tags and respective `Dockerfile` links - [`4.0.0rc4`, `4.0`, `4` (*4.0/Dockerfile*)](https://github.com/docker-library/celery/blob/8e10b9f6008ca34cd9ef2a74f032531bd44193b4/4.0/Dockerfile) - [`3.1.23`, `3.1`, `3`, `latest` (*3.1/Dockerfile*)](https://github.com/docker-library/celery/blob/2b56f641be3c38c4367fa7501268b43398199922/3.1/Dockerfile) For more information about this image and its history, please see [the relevant manifest file (`library/celery`)](https://github.com/docker-library/official-images/blob/master/library/celery). This image is updated via [pull requests to the `docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images/pulls?q=label%3Alibrary%2Fcelery). For detailed information about the virtual/transfer sizes and individual layers of each of the above supported tags, please see [the `repos/celery/tag-details.md` file](https://github.com/docker-library/repo-info/blob/master/repos/celery/tag-details.md) in [the `docker-library/repo-info` GitHub repo](https://github.com/docker-library/repo-info). # Celery Celery is an open source asynchronous task queue/job queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well. > [wikipedia.org/wiki/Celery_Task_Queue](https://en.wikipedia.org/wiki/Celery_Task_Queue) # How to use this image ## start a celery worker (RabbitMQ Broker) ```console $ docker run --link some-rabbit:rabbit --name some-celery -d celery ``` ### check the status of the cluster ```console $ docker run --link some-rabbit:rabbit --rm celery celery status ``` ## start a celery worker (Redis Broker) ```console $ docker run --link some-redis:redis -e CELERY_BROKER_URL=redis://redis --name some-celery -d celery ``` ### check the status of the cluster ```console $ docker run --link some-redis:redis -e CELERY_BROKER_URL=redis://redis --rm celery celery status ``` # Supported Docker versions This image is officially supported on Docker version 1.12.1. Support for older versions (down to 1.6) is provided on a best-effort basis. Please see [the Docker installation documentation](https://docs.docker.com/installation/) for details on how to upgrade your Docker daemon. # User Feedback ## Documentation Documentation for this image is stored in the [`celery/` directory](https://github.com/docker-library/docs/tree/master/celery) of the [`docker-library/docs` GitHub repo](https://github.com/docker-library/docs). Be sure to familiarize yourself with the [repository's `README.md` file](https://github.com/docker-library/docs/blob/master/README.md) before attempting a pull request. ## Issues If you have any problems with or questions about this image, please contact us through a [GitHub issue](https://github.com/docker-library/celery/issues). If the issue is related to a CVE, please check for [a `cve-tracker` issue on the `official-images` repository first](https://github.com/docker-library/official-images/issues?q=label%3Acve-tracker). You can also reach many of the official image maintainers via the `#docker-library` IRC channel on [Freenode](https://freenode.net). ## Contributing You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can. Before you start to code, we recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/celery/issues), especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing.