Bitnami/containers
2
0
Fork 0
mirror of https://github.com/bitnami/containers.git synced 2026-03-26 23:08:08 +08:00
Code Issues Packages Projects Releases Wiki Activity

Remove extra READMEs in branch folders (#69257)

Browse Source
This commit is contained in:
Tomas Pizarro
2024-07-15 16:43:56 +02:00
committed by GitHub
parent 536990b719
commit b368a555e9
25 changed files with 0 additions and 7190 deletions
Download Patch File Download Diff File Expand all files Collapse all files

261
bitnami/appsmith/1/debian-12/README.md
View File

@@ -1,261 +0,0 @@
# Bitnami package for Appsmith
## What is Appsmith?
> Appsmith is an open source platform for building and maintaining internal tools, such as custom dashboards, admin panels or CRUD apps.
[Overview of Appsmith](https://www.appsmith.com/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run -it --name appsmith bitnami/appsmith:latest
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Appsmith in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Appsmith Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/appsmith).
```console
docker pull bitnami/appsmith:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/appsmith/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/appsmith:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of Appsmith, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/appsmith:latest
```
or if you're using Docker Compose, update the value of the image property to `bitnami/appsmith:latest`.
#### Step 2: Remove the currently running container
```console
docker rm -v appsmith
```
or using Docker Compose:
```console
docker-compose rm -v appsmith
```
#### Step 3: Run the new image
Re-create your container from the new image.
```console
docker run --name appsmith bitnami/appsmith:latest
```
or using Docker Compose:
```console
docker-compose up appsmith
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|---------------------------------|---------------------------------------------------------|-----------------------|
| `ALLOW_EMPTY_PASSWORD` | Allow an empty password. | `no` |
| `APPSMITH_USERNAME` | Appsmith default username. | `user` |
| `APPSMITH_PASSWORD` | Appsmith default password. | `bitnami123` |
| `APPSMITH_EMAIL` | Appsmith default email. | `user@example.com` |
| `APPSMITH_MODE` | Appsmith service to run (can be backend, client or UI). | `backend` |
| `APPSMITH_ENCRYPTION_PASSWORD` | Appsmith database encryption password. | `bitnami123` |
| `APPSMITH_ENCRYPTION_SALT` | Appsmith database encryption salt. | `nil` |
| `APPSMITH_API_HOST` | Appsmith API host. | `appsmith-api` |
| `APPSMITH_API_PORT` | Appsmith API port. | `8080` |
| `APPSMITH_UI_HTTP_PORT` | Appsmith UI HTTP port. | `8080` |
| `APPSMITH_UI_HTTPS_PORT` | Appsmith UI HTTPS port. | `8443` |
| `APPSMITH_RTS_HOST` | Appsmith RTS port. | `appsmith-rts` |
| `APPSMITH_RTS_PORT` | Appsmith RTS port. | `8091` |
| `APPSMITH_DATABASE_HOST` | Database server hosts (comma-separated list). | `mongodb` |
| `APPSMITH_DATABASE_PORT_NUMBER` | Database server port. | `27017` |
| `APPSMITH_DATABASE_NAME` | Database name. | `bitnami_appsmith` |
| `APPSMITH_DATABASE_USER` | Database user name. | `bn_appsmith` |
| `APPSMITH_DATABASE_PASSWORD` | Database user password. | `nil` |
| `APPSMITH_DATABASE_INIT_DELAY` | Time to wait before the database is actually ready. | `0` |
| `APPSMITH_REDIS_HOST` | Redis server host. | `redis` |
| `APPSMITH_REDIS_PORT_NUMBER` | Redis server port. | `6379` |
| `APPSMITH_REDIS_PASSWORD` | Redis user password. | `nil` |
| `APPSMITH_STARTUP_TIMEOUT` | Appsmith startup check timeout. | `120` |
| `APPSMITH_STARTUP_ATTEMPTS` | Appsmith startup check attempts. | `5` |
| `APPSMITH_DATA_TO_PERSIST` | Data to persist from installations. | `$APPSMITH_CONF_FILE` |
#### Read-only environment variables
| Name | Description | Value |
|-----------------------------|-------------------------------------------|-------------------------------------|
| `APPSMITH_BASE_DIR` | Appsmith installation directory. | `${BITNAMI_ROOT_DIR}/appsmith` |
| `APPSMITH_VOLUME_DIR` | Appsmith volume directory. | `/bitnami/appsmith` |
| `APPSMITH_LOG_DIR` | Appsmith logs directory. | `${APPSMITH_BASE_DIR}/logs` |
| `APPSMITH_LOG_FILE` | Appsmith log file. | `${APPSMITH_LOG_DIR}/appsmith.log` |
| `APPSMITH_CONF_DIR` | Appsmith configuration directory. | `${APPSMITH_BASE_DIR}/conf` |
| `APPSMITH_DEFAULT_CONF_DIR` | Appsmith default configuration directory. | `${APPSMITH_BASE_DIR}/conf.default` |
| `APPSMITH_CONF_FILE` | Appsmith configuration file. | `${APPSMITH_CONF_DIR}/docker.env` |
| `APPSMITH_TMP_DIR` | Appsmith temporary directory. | `${APPSMITH_BASE_DIR}/tmp` |
| `APPSMITH_PID_FILE` | Appsmith PID file. | `${APPSMITH_TMP_DIR}/appsmith.pid` |
| `APPSMITH_DAEMON_USER` | Appsmith daemon system user. | `appsmith` |
| `APPSMITH_DAEMON_GROUP` | Appsmith daemon system group. | `appsmith` |
When you start the Appsmith image, you can adjust the configuration of the instance by passing one or more environment variables either on the docker-compose file or on the `docker run` command line. Please note that some variables are only considered when the container is started for the first time. If you want to add a new environment variable:
* For docker-compose add the variable name and value under the application section in the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/appsmith/docker-compose.yml) file present in this repository:
```yaml
appsmith-api:
...
environment:
- APPSMITH_PASSWORD=my_password
...
```
* For manual execution add a `--env` option with each variable and value:
```console
$ docker run -d --name appsmith-api -p 80:8080 -p 443:8443 \
--env APPSMITH_PASSWORD=my_password \
--env APPSMITH_MODE=backend \
--network appsmith-tier \
--volume /path/to/appsmith-persistence:/bitnami \
bitnami/appsmith:latest
```
Available environment variables:
#### Run mode
Appsmith supports three running modes:
* Backend: The Appsmith API. It is the essential functional element of Appsmith.
* RTS: Necessary for performing real-time editing of the applications created by Appsmith.
* Client: Contains the UI of Appsmith. This is the main entrypoint for users.
The running mode is defined via the `APPSMITH_MODE` environment variable. The possible values are `backend`, `rts` and `client`.
##### Connect Appsmith container to an existing database
The Bitnami Appsmith container supports connecting the Appsmith application to an external database. This would be an example of using an external database for Appsmith.
* Modify the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/appsmith/docker-compose.yml) file present in this repository:
```diff
appsmith:
...
environment:
- - APPSMITH_DATABASE_HOST=mongodb
+ - APPSMITH_DATABASE_HOST=mongodb_host
- APPSMITH_DATABASE_PORT_NUMBER=27017
- APPSMITH_DATABASE_NAME=appsmith_db
- APPSMITH_DATABASE_USER=appsmith_user
- - ALLOW_EMPTY_PASSWORD=yes
+ - APPSMITH_DATABASE_PASSWORD=appsmith_password
...
```
* For manual execution:
```console
$ docker run -d --name appsmith\
-p 8080:8080 -p 8443:8443 \
--network appsmith-network \
--env APPSMITH_DATABASE_HOST=mongodb_host \
--env APPSMITH_DATABASE_PORT_NUMBER=27017 \
--env APPSMITH_DATABASE_NAME=appsmith_db \
--env APPSMITH_DATABASE_USER=appsmith_user \
--env APPSMITH_DATABASE_PASSWORD=appsmith_password \
--volume appsmith_data:/bitnami/appsmith \
bitnami/appsmith:latest
```
## Logging
The Bitnami Appsmith Docker image sends the container logs to `stdout`. To view the logs:
```console
docker logs wordpress
```
Or using Docker Compose:
```console
docker-compose logs wordpress
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/appsmith).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this Docker image. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright © 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

568
bitnami/cassandra/4.0/debian-12/README.md
View File

@@ -1,568 +0,0 @@
# Bitnami package for Apache Cassandra
## What is Apache Cassandra?
> Apache Cassandra is an open source distributed database management system designed to handle large amounts of data across many servers, providing high availability with no single point of failure.
[Overview of Apache Cassandra](http://cassandra.apache.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run --name cassandra bitnami/cassandra:latest
```
You can find the default credentials and available configuration options in the [Environment Variables](#environment-variables) section.
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Apache Cassandra in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## How to deploy Apache Cassandra in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami Apache Cassandra Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/cassandra).
Bitnami containers can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Apache Cassandra Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/cassandra).
```console
docker pull bitnami/cassandra:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/cassandra/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/cassandra:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Persisting your application
If you remove the container all your data and configurations will be lost, and the next time you run the image the database will be reinitialized. To avoid this loss of data, you should mount a volume that will persist even after the container is removed.
For persistence you should mount a directory at the `/bitnami` path. If the mounted directory is empty, it will be initialized on the first run.
```console
docker run \
-v /path/to/cassandra-persistence:/bitnami \
bitnami/cassandra:latest
```
or using Docker Compose:
```yaml
cassandra:
image: bitnami/cassandra:latest
volumes:
- /path/to/cassandra-persistence:/bitnami
```
> NOTE: As this is a non-root container, the mounted files and directories must have the proper permissions for the UID `1001`.
## Connecting to other containers
Using [Docker container networking](https://docs.docker.com/engine/userguide/networking/), an Apache Cassandra server running inside a container can easily be accessed by your application containers.
Containers attached to the same network can communicate with each other using the container name as the hostname.
### Using the Command Line
In this example, we will create an Apache Cassandra client instance that will connect to the server instance that is running on the same docker network as the client.
#### Step 1: Create a network
```console
docker network create app-tier --driver bridge
```
#### Step 2: Launch the Apache Cassandra server instance
Use the `--network app-tier` argument to the `docker run` command to attach the Apache Cassandra container to the `app-tier` network.
```console
docker run -d --name cassandra-server \
--network app-tier \
bitnami/cassandra:latest
```
#### Step 3: Launch your Apache Cassandra client instance
Finally we create a new container instance to launch the Apache Cassandra client and connect to the server created in the previous step:
```console
docker run -it --rm \
--network app-tier \
bitnami/cassandra:latest cqlsh --username cassandra --password cassandra cassandra-server
```
### Using a Docker Compose file
When not specified, Docker Compose automatically sets up a new network and attaches all deployed services to that network. However, we will explicitly define a new `bridge` network named `app-tier`. In this example we assume that you want to connect to the Apache Cassandra server from your own custom application image which is identified in the following snippet by the service name `myapp`.
```yaml
version: '2'
networks:
app-tier:
driver: bridge
services:
cassandra:
image: 'bitnami/cassandra:latest'
networks:
- app-tier
myapp:
image: 'YOUR_APPLICATION_IMAGE'
networks:
- app-tier
```
> **IMPORTANT**:
>
> 1. Please update the **YOUR_APPLICATION_IMAGE_** placeholder in the above snippet with your application image
> 2. In your application container, use the hostname `cassandra` to connect to the Apache Cassandra server
Launch the containers using:
```console
docker-compose up -d
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|----------------------------------------------------|-----------------------------------------------------------------------------------------|---------------------------------------|
| `CASSANDRA_MOUNTED_CONF_DIR` | Cassandra directory for mounted configuration files | `${DB_VOLUME_DIR}/conf` |
| `CASSANDRA_CLIENT_ENCRYPTION` | Enable client encryption | `false` |
| `CASSANDRA_CLUSTER_NAME` | Cassandra cluster name | `My Cluster` |
| `CASSANDRA_DATACENTER` | Cassandra datacenter name | `dc1` |
| `CASSANDRA_ENABLE_REMOTE_CONNECTIONS` | Enable connection from remote locations | `true` |
| `CASSANDRA_ENABLE_RPC` | Enable RPC endpoint in Cassandra | `false` |
| `CASSANDRA_ENABLE_USER_DEFINED_FUNCTIONS` | Enable user defined functions | `false` |
| `CASSANDRA_ENABLE_SCRIPTED_USER_DEFINED_FUNCTIONS` | Enable scripted user defined functions | `false` |
| `CASSANDRA_ENDPOINT_SNITCH` | Name of the cluster endpoint snitch | `SimpleSnitch` |
| `CASSANDRA_HOST` | Cassandra host name | `nil` |
| `CASSANDRA_INTERNODE_ENCRYPTION` | Internode encryption type | `none` |
| `CASSANDRA_NUM_TOKENS` | Number of tokens in cluster connection | `256` |
| `CASSANDRA_PASSWORD_SEEDER` | Set node as password seeder in the cluster | `no` |
| `CASSANDRA_SEEDS` | List of cluster seeds | `$DB_HOST` |
| `CASSANDRA_PEERS` | List of cluster peers | `$DB_SEEDS` |
| `CASSANDRA_NODES` | List of cluster nodes (seeders and non seeders) | `nil` |
| `CASSANDRA_RACK` | Cassandra rack name | `rack1` |
| `CASSANDRA_BROADCAST_ADDRESS` | Node broadcast address | `nil` |
| `CASSANDRA_AUTOMATIC_SSTABLE_UPGRADE` | Automatically upgrade sstables after upgrade | `false` |
| `CASSANDRA_STARTUP_CQL` | Startup CQL commands to run at boot | `nil` |
| `CASSANDRA_IGNORE_INITDB_SCRIPTS` | Ignore the execution of init scripts | `no` |
| `CASSANDRA_CQL_PORT_NUMBER` | CQL port | `9042` |
| `CASSANDRA_JMX_PORT_NUMBER` | JMX port | `7199` |
| `CASSANDRA_TRANSPORT_PORT_NUMBER` | Transport port | `7000` |
| `CASSANDRA_CQL_MAX_RETRIES` | Maximum retries for CQL startup operations | `20` |
| `CASSANDRA_CQL_SLEEP_TIME` | Sleep time for CQL startup operations | `5` |
| `CASSANDRA_INIT_MAX_RETRIES` | Maximum retries for init startup operations | `100` |
| `CASSANDRA_INIT_SLEEP_TIME` | Sleep time for init startup operations | `5` |
| `CASSANDRA_PEER_CQL_MAX_RETRIES` | Maximum retries for peer startup operations | `100` |
| `CASSANDRA_PEER_CQL_SLEEP_TIME` | Sleep time for peer startup operations | `10` |
| `CASSANDRA_DELAY_START_TIME` | Delay Cassandra start by the number of provided seconds | `10` |
| `CASSANDRA_AUTO_SNAPSHOT_TTL` | Take an automatic snapshot of the data before truncating a keyspace or dropping a table | `30d` |
| `ALLOW_EMPTY_PASSWORD` | Allow no credentials in the installation. | `no` |
| `CASSANDRA_AUTHORIZER` | Cassandra connection authorizer | `CassandraAuthorizer` |
| `CASSANDRA_AUTHENTICATOR` | Cassandra connection authenticator | `PasswordAuthenticator` |
| `CASSANDRA_USER` | Cassandra username | `cassandra` |
| `CASSANDRA_PASSWORD` | Cassandra password | `nil` |
| `CASSANDRA_KEYSTORE_PASSWORD` | Cassandra keystore password | `cassandra` |
| `CASSANDRA_TRUSTSTORE_PASSWORD` | Cassandra truststore password | `cassandra` |
| `CASSANDRA_KEYSTORE_LOCATION` | Cassandra keystore location | `${DB_VOLUME_DIR}/secrets/keystore` |
| `CASSANDRA_TRUSTSTORE_LOCATION` | Cassandra truststore location | `${DB_VOLUME_DIR}/secrets/truststore` |
| `CASSANDRA_TMP_P12_FILE` | Cassandra truststore location | `${DB_TMP_DIR}/keystore.p12` |
| `CASSANDRA_SSL_CERT_FILE` | Cassandra SSL certificate location | `${DB_VOLUME_DIR}/certs/tls.crt` |
| `CASSANDRA_SSL_KEY_FILE` | Cassandra SSL keyfile location | `${DB_VOLUME_DIR}/certs/tls.key` |
| `CASSANDRA_SSL_CA_FILE` | Cassandra SSL CA location | `nil` |
| `CASSANDRA_SSL_VALIDATE` | Perform SSL validation on the certificates | `false` |
| `SSL_VERSION` | TLS version to use when connecting. | `TLSv1_2` |
#### Read-only environment variables
| Name | Description | Value |
|---------------------------------------|---------------------------------------------------------------------------------|-------------------------------------------------|
| `DB_FLAVOR` | Database flavor. Valid values: `cassandra` or `scylladb`. | `cassandra` |
| `CASSANDRA_BASE_DIR` | Cassandra installation directory | `/opt/bitnami/cassandra` |
| `CASSANDRA_BIN_DIR` | Cassandra executables directory | `${DB_BASE_DIR}/bin` |
| `CASSANDRA_VOLUME_DIR` | Persistence base directory | `/bitnami/cassandra` |
| `CASSANDRA_DATA_DIR` | Cassandra data directory | `${DB_VOLUME_DIR}/data` |
| `CASSANDRA_COMMITLOG_DIR` | Cassandra commit log directory | `${DB_DATA_DIR}/commitlog` |
| `CASSANDRA_INITSCRIPTS_DIR` | Path to the Cassandra container init scripts directory | `/docker-entrypoint-initdb.d` |
| `CASSANDRA_LOG_DIR` | Cassandra logs directory | `${DB_BASE_DIR}/logs` |
| `CASSANDRA_TMP_DIR` | Cassandra temporary directory | `${DB_BASE_DIR}/tmp` |
| `JAVA_BASE_DIR` | Java base directory | `${BITNAMI_ROOT_DIR}/java` |
| `JAVA_BIN_DIR` | Java binary directory | `${JAVA_BASE_DIR}/bin` |
| `PYTHON_BASE_DIR` | Python base directory | `${BITNAMI_ROOT_DIR}/python` |
| `PYTHON_BIN_DIR` | Python binary directory | `${PYTHON_BASE_DIR}/bin` |
| `CASSANDRA_LOG_FILE` | Path to the Cassandra log file | `${DB_LOG_DIR}/cassandra.log` |
| `CASSANDRA_FIRST_BOOT_LOG_FILE` | Path to the Cassandra first boot log file | `${DB_LOG_DIR}/cassandra_first_boot.log` |
| `CASSANDRA_INITSCRIPTS_BOOT_LOG_FILE` | Path to the Cassandra init scripts log file | `${DB_LOG_DIR}/cassandra_init_scripts_boot.log` |
| `CASSANDRA_PID_FILE` | Path to the Cassandra pid file | `${DB_TMP_DIR}/cassandra.pid` |
| `CASSANDRA_DAEMON_USER` | Cassandra system user | `cassandra` |
| `CASSANDRA_DAEMON_GROUP` | Cassandra system group | `cassandra` |
| `CASSANDRA_CONF_DIR` | Cassandra configuration directory | `${DB_BASE_DIR}/conf` |
| `CASSANDRA_DEFAULT_CONF_DIR` | Cassandra default configuration directory | `${DB_BASE_DIR}/conf.default` |
| `CASSANDRA_CONF_FILE` | Path to Cassandra configuration file | `${DB_CONF_DIR}/cassandra.yaml` |
| `CASSANDRA_RACKDC_FILE` | Path to Cassandra cassandra-rackdc.properties file | `${DB_CONF_DIR}/cassandra-rackdc.properties` |
| `CASSANDRA_LOGBACK_FILE` | Path to Cassandra logback.xml file | `${DB_CONF_DIR}/logback.xml` |
| `CASSANDRA_COMMITLOG_ARCHIVING_FILE` | Path to Cassandra commitlog_archiving.properties file | `${DB_CONF_DIR}/commitlog_archiving.properties` |
| `CASSANDRA_ENV_FILE` | Path to Cassandra cassandra-env.sh file | `${DB_CONF_DIR}/cassandra-env.sh` |
| `CASSANDRA_MOUNTED_CONF_PATH` | Relative path (in mounted volume) to Cassandra configuration file | `cassandra.yaml` |
| `CASSANDRA_MOUNTED_RACKDC_PATH` | Relative path (in mounted volume) to Cassandra cassandra-rackdc-properties file | `cassandra-rackdc.properties` |
| `CASSANDRA_MOUNTED_ENV_PATH` | Relative path (in mounted volume) to Cassandra cassandra-env.sh file | `cassandra-env.sh` |
| `CASSANDRA_MOUNTED_LOGBACK_PATH` | Path to Cassandra logback.xml file | `logback.xml` |
Additionally, any environment variable beginning with the following prefix will be mapped to its corresponding Apache Cassandra key in the proper file:
* `CASSANDRA_CFG_ENV_`: Will add the corresponding key and the provided value to `cassandra-env.sh`.
* `CASSANDRA_CFG_RACKDC_`: Will add the corresponding key and the provided value to `cassandra-rackdc.properties`.
* `CASSANDRA_CFG_COMMITLOG_`: Will add the corresponding key and the provided value to `commitlog_archiving.properties`.
* `CASSANDRA_CFG_YAML_`: Will add the corresponding key and the provided value to `cassandra.yaml`.
For example, use `CASSANDRA_CFG_RACKDC_PREFER_LOCAL=true` in order to configure `prefer_local` in `cassandra-rackdc.properties`. Or, use `CASSANDRA_CFG_YAML_INTERNODE_COMPRESSION=all` in order to set `internode_compression` to `all` in `cassandra.yaml`.
**NOTE:** Environment variables will be omitted when mounting a configuration file
When you start the cassandra image, you can adjust the configuration of the instance by passing one or more environment variables either on the docker-compose file or on the `docker run` command line. If you want to add a new environment variable:
* For docker-compose add the variable name and value under the application section:
```yaml
cassandra:
image: bitnami/cassandra:latest
environment:
- CASSANDRA_TRANSPORT_PORT_NUMBER=7000
```
* For manual execution add a `-e` option with each variable and value:
```console
$ docker run --name cassandra -d -p 7000:7000 --network=cassandra_network \
-e CASSANDRA_TRANSPORT_PORT_NUMBER=7000 \
-v /your/local/path/bitnami/cassandra:/bitnami \
bitnami/cassandra
```
### Setting the server password on first run
Passing the `CASSANDRA_PASSWORD` environment variable along with `CASSANDRA_PASSWORD_SEEDER=yes` when running the image for the first time will set the Apache Cassandra server password to the value of `CASSANDRA_PASSWORD`.
```console
docker run --name cassandra \
-e CASSANDRA_PASSWORD_SEEDER=yes \
-e CASSANDRA_PASSWORD=password123 \
bitnami/cassandra:latest
```
or using Docker Compose:
```yaml
cassandra:
image: bitnami/cassandra:latest
environment:
- CASSANDRA_PASSWORD_SEEDER=yes
- CASSANDRA_PASSWORD=password123
```
#### Step 1: Create a new network
```console
docker network create cassandra_network
```
#### Step 2: Create a first node
```console
docker run --name cassandra-node1 \
--net=cassandra_network \
-p 9042:9042 \
-e CASSANDRA_CLUSTER_NAME=cassandra-cluster \
-e CASSANDRA_SEEDS=cassandra-node1,cassandra-node2 \
-e CASSANDRA_PASSWORD_SEEDER=yes \
-e CASSANDRA_PASSWORD=mypassword \
bitnami/cassandra:latest
```
In the above command the container is added to a cluster named `cassandra-cluster` using the `CASSANDRA_CLUSTER_NAME`. The `CASSANDRA_CLUSTER_HOSTS` parameter set the name of the nodes that set the cluster so we will need to launch other container for the second node. Finally the `CASSANDRA_NODE_NAME` parameter allows to indicate a known name for the node, otherwise cassandra will generate a random one.
#### Step 3: Create a second node
```console
docker run --name cassandra-node2 \
--net=cassandra_network \
-e CASSANDRA_CLUSTER_NAME=cassandra-cluster \
-e CASSANDRA_SEEDS=cassandra-node1,cassandra-node2 \
-e CASSANDRA_PASSWORD=mypassword \
bitnami/cassandra:latest
```
In the above command a new cassandra node is being added to the cassandra cluster indicated by `CASSANDRA_CLUSTER_NAME`.
You now have a two node Apache Cassandra cluster up and running which can be scaled by adding/removing nodes.
With Docker Compose the cluster configuration can be setup using:
```yaml
version: '2'
services:
cassandra-node1:
image: bitnami/cassandra:latest
environment:
- CASSANDRA_CLUSTER_NAME=cassandra-cluster
- CASSANDRA_SEEDS=cassandra-node1,cassandra-node2
- CASSANDRA_PASSWORD_SEEDER=yes
- CASSANDRA_PASSWORD=password123
cassandra-node2:
image: bitnami/cassandra:latest
environment:
- CASSANDRA_CLUSTER_NAME=cassandra-cluster
- CASSANDRA_SEEDS=cassandra-node1,cassandra-node2
- CASSANDRA_PASSWORD=password123
```
### Initializing with custom scripts
When the container is executed for the first time, it will execute the files with extensions `.sh`, `.cql` or `.cql.gz` located at `/docker-entrypoint-initdb.d` in sort'ed order by filename. This behavior can be skipped by setting the environment variable `CASSANDRA_IGNORE_INITDB_SCRIPTS` to a value other than `yes` or `true`.
In order to have your custom files inside the docker image you can mount them as a volume.
```console
docker run --name cassandra \
-v /path/to/init-scripts:/docker-entrypoint-initdb.d \
-v /path/to/cassandra-persistence:/bitnami
bitnami/cassandra:latest
```
Or with docker-compose
```yaml
cassandra:
image: bitnami/cassandra:latest
volumes:
- /path/to/init-scripts:/docker-entrypoint-initdb.d
- /path/to/cassandra-persistence:/bitnami
```
### Configuration file
The image looks for configurations in `/bitnami/cassandra/conf/`. As mentioned in [Persisting your application](#persisting-your-application) you can mount a volume at `/bitnami` and copy/edit the configurations in the `/path/to/cassandra-persistence/cassandra/conf/`. The default configurations will be populated to the `conf/` directory if it's empty.
#### Step 1: Run the Apache Cassandra image
Run the Apache Cassandra image, mounting a directory from your host.
```console
docker run --name cassandra \
-v /path/to/cassandra-persistence:/bitnami \
bitnami/cassandra:latest
```
or using Docker Compose:
```yaml
cassandra:
image: bitnami/cassandra:latest
volumes:
- /path/to/cassandra-persistence:/bitnami
```
#### Step 2: Edit the configuration
Edit the configuration on your host using your favorite editor.
```console
vi /path/to/cassandra-persistence/cassandra/conf/cassandra.yaml
```
#### Step 3: Restart Apache Cassandra
After changing the configuration, restart your Apache Cassandra container for changes to take effect.
```console
docker restart cassandra
```
or using Docker Compose:
```console
docker-compose restart cassandra
```
Refer to the [configuration](http://docs.datastax.com/en/cassandra/3.x/cassandra/configuration/configTOC.html) manual for the complete list of configuration options.
## TLS Encryption
The Bitnami Apache Cassandra Docker image allows configuring TLS encryption between nodes and between server-client. This is done by mounting in `/bitnami/cassandra/secrets` two files:
* `keystore`: File with the server keystore
* `truststore`: File with the server truststore
Apart from that, the following environment variables must be set:
* `CASSANDRA_KEYSTORE_PASSWORD`: Password for accessing the keystore.
* `CASSANDRA_TRUSTSTORE_PASSWORD`: Password for accessing the truststore.
* `CASSANDRA_INTERNODE_ENCRYPTION`: Sets the type of encryption between nodes. The default value is `none`. Can be set to `all`, `none`, `dc` or `rack`.
* `CASSANDRA_CLIENT_ENCRYPTION`: Enables client-server encryption. The default value is `false`.
## Logging
The Bitnami Apache Cassandra Docker image sends the container logs to the `stdout`. To view the logs:
```console
docker logs cassandra
```
or using Docker Compose:
```console
docker-compose logs cassandra
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of Apache Cassandra, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/cassandra:latest
```
or if you're using Docker Compose, update the value of the image property to
`bitnami/cassandra:latest`.
#### Step 2: Stop and backup the currently running container
Stop the currently running container using the command
```console
docker stop cassandra
```
or using Docker Compose:
```console
docker-compose stop cassandra
```
Next, take a snapshot of the persistent volume `/path/to/cassandra-persistence` using:
```console
rsync -a /path/to/cassandra-persistence /path/to/cassandra-persistence.bkp.$(date +%Y%m%d-%H.%M.%S)
```
#### Step 3: Remove the currently running container
```console
docker rm -v cassandra
```
or using Docker Compose:
```console
docker-compose rm -v cassandra
```
#### Step 4: Run the new image
Re-create your container from the new image.
```console
docker run --name cassandra bitnami/cassandra:latest
```
or using Docker Compose:
```console
docker-compose up cassandra
```
## Notable Changes
## 3.11.10-debian-10-r81 Split branch 3
* Branch 3 has been split into branch 3.0 and 3.11 mirroring the upstream Apache Cassandra repo.
### 3.11.4-debian-9-r188 and 3.11.4-ol-7-r201
* Decrease the size of the container. The configuration logic is now based on Bash scripts in the `rootfs/` folder.
### 3.11.3-r129
-The Apache Cassandra container now adds the possibility to inject custom initialization scripts by mounting cql and sh files in `/docker-entrypoint-initdb.d`. See [this section](#initializing-with-custom-scripts) for more information.
### 3.11.2-r22
* The Apache Cassandra container has been migrated to a non-root user approach. Previously the container ran as the `root` user and the Apache Cassandra daemon was started as the `cassandra` user. From now on, both the container and the Apache Cassandra daemon run as user `1001`. As a consequence, the data directory must be writable by that user. You can revert this behavior by changing `USER 1001` to `USER root` in the Dockerfile.
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/cassandra).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues), or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

568
bitnami/cassandra/4.1/debian-12/README.md
View File

@@ -1,568 +0,0 @@
# Bitnami package for Apache Cassandra
## What is Apache Cassandra?
> Apache Cassandra is an open source distributed database management system designed to handle large amounts of data across many servers, providing high availability with no single point of failure.
[Overview of Apache Cassandra](http://cassandra.apache.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run --name cassandra bitnami/cassandra:latest
```
You can find the default credentials and available configuration options in the [Environment Variables](#environment-variables) section.
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Apache Cassandra in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## How to deploy Apache Cassandra in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami Apache Cassandra Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/cassandra).
Bitnami containers can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Apache Cassandra Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/cassandra).
```console
docker pull bitnami/cassandra:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/cassandra/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/cassandra:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Persisting your application
If you remove the container all your data and configurations will be lost, and the next time you run the image the database will be reinitialized. To avoid this loss of data, you should mount a volume that will persist even after the container is removed.
For persistence you should mount a directory at the `/bitnami` path. If the mounted directory is empty, it will be initialized on the first run.
```console
docker run \
-v /path/to/cassandra-persistence:/bitnami \
bitnami/cassandra:latest
```
or using Docker Compose:
```yaml
cassandra:
image: bitnami/cassandra:latest
volumes:
- /path/to/cassandra-persistence:/bitnami
```
> NOTE: As this is a non-root container, the mounted files and directories must have the proper permissions for the UID `1001`.
## Connecting to other containers
Using [Docker container networking](https://docs.docker.com/engine/userguide/networking/), an Apache Cassandra server running inside a container can easily be accessed by your application containers.
Containers attached to the same network can communicate with each other using the container name as the hostname.
### Using the Command Line
In this example, we will create an Apache Cassandra client instance that will connect to the server instance that is running on the same docker network as the client.
#### Step 1: Create a network
```console
docker network create app-tier --driver bridge
```
#### Step 2: Launch the Apache Cassandra server instance
Use the `--network app-tier` argument to the `docker run` command to attach the Apache Cassandra container to the `app-tier` network.
```console
docker run -d --name cassandra-server \
--network app-tier \
bitnami/cassandra:latest
```
#### Step 3: Launch your Apache Cassandra client instance
Finally we create a new container instance to launch the Apache Cassandra client and connect to the server created in the previous step:
```console
docker run -it --rm \
--network app-tier \
bitnami/cassandra:latest cqlsh --username cassandra --password cassandra cassandra-server
```
### Using a Docker Compose file
When not specified, Docker Compose automatically sets up a new network and attaches all deployed services to that network. However, we will explicitly define a new `bridge` network named `app-tier`. In this example we assume that you want to connect to the Apache Cassandra server from your own custom application image which is identified in the following snippet by the service name `myapp`.
```yaml
version: '2'
networks:
app-tier:
driver: bridge
services:
cassandra:
image: 'bitnami/cassandra:latest'
networks:
- app-tier
myapp:
image: 'YOUR_APPLICATION_IMAGE'
networks:
- app-tier
```
> **IMPORTANT**:
>
> 1. Please update the **YOUR_APPLICATION_IMAGE_** placeholder in the above snippet with your application image
> 2. In your application container, use the hostname `cassandra` to connect to the Apache Cassandra server
Launch the containers using:
```console
docker-compose up -d
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|----------------------------------------------------|-----------------------------------------------------------------------------------------|---------------------------------------|
| `CASSANDRA_MOUNTED_CONF_DIR` | Cassandra directory for mounted configuration files | `${DB_VOLUME_DIR}/conf` |
| `CASSANDRA_CLIENT_ENCRYPTION` | Enable client encryption | `false` |
| `CASSANDRA_CLUSTER_NAME` | Cassandra cluster name | `My Cluster` |
| `CASSANDRA_DATACENTER` | Cassandra datacenter name | `dc1` |
| `CASSANDRA_ENABLE_REMOTE_CONNECTIONS` | Enable connection from remote locations | `true` |
| `CASSANDRA_ENABLE_RPC` | Enable RPC endpoint in Cassandra | `false` |
| `CASSANDRA_ENABLE_USER_DEFINED_FUNCTIONS` | Enable user defined functions | `false` |
| `CASSANDRA_ENABLE_SCRIPTED_USER_DEFINED_FUNCTIONS` | Enable scripted user defined functions | `false` |
| `CASSANDRA_ENDPOINT_SNITCH` | Name of the cluster endpoint snitch | `SimpleSnitch` |
| `CASSANDRA_HOST` | Cassandra host name | `nil` |
| `CASSANDRA_INTERNODE_ENCRYPTION` | Internode encryption type | `none` |
| `CASSANDRA_NUM_TOKENS` | Number of tokens in cluster connection | `256` |
| `CASSANDRA_PASSWORD_SEEDER` | Set node as password seeder in the cluster | `no` |
| `CASSANDRA_SEEDS` | List of cluster seeds | `$DB_HOST` |
| `CASSANDRA_PEERS` | List of cluster peers | `$DB_SEEDS` |
| `CASSANDRA_NODES` | List of cluster nodes (seeders and non seeders) | `nil` |
| `CASSANDRA_RACK` | Cassandra rack name | `rack1` |
| `CASSANDRA_BROADCAST_ADDRESS` | Node broadcast address | `nil` |
| `CASSANDRA_AUTOMATIC_SSTABLE_UPGRADE` | Automatically upgrade sstables after upgrade | `false` |
| `CASSANDRA_STARTUP_CQL` | Startup CQL commands to run at boot | `nil` |
| `CASSANDRA_IGNORE_INITDB_SCRIPTS` | Ignore the execution of init scripts | `no` |
| `CASSANDRA_CQL_PORT_NUMBER` | CQL port | `9042` |
| `CASSANDRA_JMX_PORT_NUMBER` | JMX port | `7199` |
| `CASSANDRA_TRANSPORT_PORT_NUMBER` | Transport port | `7000` |
| `CASSANDRA_CQL_MAX_RETRIES` | Maximum retries for CQL startup operations | `20` |
| `CASSANDRA_CQL_SLEEP_TIME` | Sleep time for CQL startup operations | `5` |
| `CASSANDRA_INIT_MAX_RETRIES` | Maximum retries for init startup operations | `100` |
| `CASSANDRA_INIT_SLEEP_TIME` | Sleep time for init startup operations | `5` |
| `CASSANDRA_PEER_CQL_MAX_RETRIES` | Maximum retries for peer startup operations | `100` |
| `CASSANDRA_PEER_CQL_SLEEP_TIME` | Sleep time for peer startup operations | `10` |
| `CASSANDRA_DELAY_START_TIME` | Delay Cassandra start by the number of provided seconds | `10` |
| `CASSANDRA_AUTO_SNAPSHOT_TTL` | Take an automatic snapshot of the data before truncating a keyspace or dropping a table | `30d` |
| `ALLOW_EMPTY_PASSWORD` | Allow no credentials in the installation. | `no` |
| `CASSANDRA_AUTHORIZER` | Cassandra connection authorizer | `CassandraAuthorizer` |
| `CASSANDRA_AUTHENTICATOR` | Cassandra connection authenticator | `PasswordAuthenticator` |
| `CASSANDRA_USER` | Cassandra username | `cassandra` |
| `CASSANDRA_PASSWORD` | Cassandra password | `nil` |
| `CASSANDRA_KEYSTORE_PASSWORD` | Cassandra keystore password | `cassandra` |
| `CASSANDRA_TRUSTSTORE_PASSWORD` | Cassandra truststore password | `cassandra` |
| `CASSANDRA_KEYSTORE_LOCATION` | Cassandra keystore location | `${DB_VOLUME_DIR}/secrets/keystore` |
| `CASSANDRA_TRUSTSTORE_LOCATION` | Cassandra truststore location | `${DB_VOLUME_DIR}/secrets/truststore` |
| `CASSANDRA_TMP_P12_FILE` | Cassandra truststore location | `${DB_TMP_DIR}/keystore.p12` |
| `CASSANDRA_SSL_CERT_FILE` | Cassandra SSL certificate location | `${DB_VOLUME_DIR}/certs/tls.crt` |
| `CASSANDRA_SSL_KEY_FILE` | Cassandra SSL keyfile location | `${DB_VOLUME_DIR}/certs/tls.key` |
| `CASSANDRA_SSL_CA_FILE` | Cassandra SSL CA location | `nil` |
| `CASSANDRA_SSL_VALIDATE` | Perform SSL validation on the certificates | `false` |
| `SSL_VERSION` | TLS version to use when connecting. | `TLSv1_2` |
#### Read-only environment variables
| Name | Description | Value |
|---------------------------------------|---------------------------------------------------------------------------------|-------------------------------------------------|
| `DB_FLAVOR` | Database flavor. Valid values: `cassandra` or `scylladb`. | `cassandra` |
| `CASSANDRA_BASE_DIR` | Cassandra installation directory | `/opt/bitnami/cassandra` |
| `CASSANDRA_BIN_DIR` | Cassandra executables directory | `${DB_BASE_DIR}/bin` |
| `CASSANDRA_VOLUME_DIR` | Persistence base directory | `/bitnami/cassandra` |
| `CASSANDRA_DATA_DIR` | Cassandra data directory | `${DB_VOLUME_DIR}/data` |
| `CASSANDRA_COMMITLOG_DIR` | Cassandra commit log directory | `${DB_DATA_DIR}/commitlog` |
| `CASSANDRA_INITSCRIPTS_DIR` | Path to the Cassandra container init scripts directory | `/docker-entrypoint-initdb.d` |
| `CASSANDRA_LOG_DIR` | Cassandra logs directory | `${DB_BASE_DIR}/logs` |
| `CASSANDRA_TMP_DIR` | Cassandra temporary directory | `${DB_BASE_DIR}/tmp` |
| `JAVA_BASE_DIR` | Java base directory | `${BITNAMI_ROOT_DIR}/java` |
| `JAVA_BIN_DIR` | Java binary directory | `${JAVA_BASE_DIR}/bin` |
| `PYTHON_BASE_DIR` | Python base directory | `${BITNAMI_ROOT_DIR}/python` |
| `PYTHON_BIN_DIR` | Python binary directory | `${PYTHON_BASE_DIR}/bin` |
| `CASSANDRA_LOG_FILE` | Path to the Cassandra log file | `${DB_LOG_DIR}/cassandra.log` |
| `CASSANDRA_FIRST_BOOT_LOG_FILE` | Path to the Cassandra first boot log file | `${DB_LOG_DIR}/cassandra_first_boot.log` |
| `CASSANDRA_INITSCRIPTS_BOOT_LOG_FILE` | Path to the Cassandra init scripts log file | `${DB_LOG_DIR}/cassandra_init_scripts_boot.log` |
| `CASSANDRA_PID_FILE` | Path to the Cassandra pid file | `${DB_TMP_DIR}/cassandra.pid` |
| `CASSANDRA_DAEMON_USER` | Cassandra system user | `cassandra` |
| `CASSANDRA_DAEMON_GROUP` | Cassandra system group | `cassandra` |
| `CASSANDRA_CONF_DIR` | Cassandra configuration directory | `${DB_BASE_DIR}/conf` |
| `CASSANDRA_DEFAULT_CONF_DIR` | Cassandra default configuration directory | `${DB_BASE_DIR}/conf.default` |
| `CASSANDRA_CONF_FILE` | Path to Cassandra configuration file | `${DB_CONF_DIR}/cassandra.yaml` |
| `CASSANDRA_RACKDC_FILE` | Path to Cassandra cassandra-rackdc.properties file | `${DB_CONF_DIR}/cassandra-rackdc.properties` |
| `CASSANDRA_LOGBACK_FILE` | Path to Cassandra logback.xml file | `${DB_CONF_DIR}/logback.xml` |
| `CASSANDRA_COMMITLOG_ARCHIVING_FILE` | Path to Cassandra commitlog_archiving.properties file | `${DB_CONF_DIR}/commitlog_archiving.properties` |
| `CASSANDRA_ENV_FILE` | Path to Cassandra cassandra-env.sh file | `${DB_CONF_DIR}/cassandra-env.sh` |
| `CASSANDRA_MOUNTED_CONF_PATH` | Relative path (in mounted volume) to Cassandra configuration file | `cassandra.yaml` |
| `CASSANDRA_MOUNTED_RACKDC_PATH` | Relative path (in mounted volume) to Cassandra cassandra-rackdc-properties file | `cassandra-rackdc.properties` |
| `CASSANDRA_MOUNTED_ENV_PATH` | Relative path (in mounted volume) to Cassandra cassandra-env.sh file | `cassandra-env.sh` |
| `CASSANDRA_MOUNTED_LOGBACK_PATH` | Path to Cassandra logback.xml file | `logback.xml` |
Additionally, any environment variable beginning with the following prefix will be mapped to its corresponding Apache Cassandra key in the proper file:
* `CASSANDRA_CFG_ENV_`: Will add the corresponding key and the provided value to `cassandra-env.sh`.
* `CASSANDRA_CFG_RACKDC_`: Will add the corresponding key and the provided value to `cassandra-rackdc.properties`.
* `CASSANDRA_CFG_COMMITLOG_`: Will add the corresponding key and the provided value to `commitlog_archiving.properties`.
* `CASSANDRA_CFG_YAML_`: Will add the corresponding key and the provided value to `cassandra.yaml`.
For example, use `CASSANDRA_CFG_RACKDC_PREFER_LOCAL=true` in order to configure `prefer_local` in `cassandra-rackdc.properties`. Or, use `CASSANDRA_CFG_YAML_INTERNODE_COMPRESSION=all` in order to set `internode_compression` to `all` in `cassandra.yaml`.
**NOTE:** Environment variables will be omitted when mounting a configuration file
When you start the cassandra image, you can adjust the configuration of the instance by passing one or more environment variables either on the docker-compose file or on the `docker run` command line. If you want to add a new environment variable:
* For docker-compose add the variable name and value under the application section:
```yaml
cassandra:
image: bitnami/cassandra:latest
environment:
- CASSANDRA_TRANSPORT_PORT_NUMBER=7000
```
* For manual execution add a `-e` option with each variable and value:
```console
$ docker run --name cassandra -d -p 7000:7000 --network=cassandra_network \
-e CASSANDRA_TRANSPORT_PORT_NUMBER=7000 \
-v /your/local/path/bitnami/cassandra:/bitnami \
bitnami/cassandra
```
### Setting the server password on first run
Passing the `CASSANDRA_PASSWORD` environment variable along with `CASSANDRA_PASSWORD_SEEDER=yes` when running the image for the first time will set the Apache Cassandra server password to the value of `CASSANDRA_PASSWORD`.
```console
docker run --name cassandra \
-e CASSANDRA_PASSWORD_SEEDER=yes \
-e CASSANDRA_PASSWORD=password123 \
bitnami/cassandra:latest
```
or using Docker Compose:
```yaml
cassandra:
image: bitnami/cassandra:latest
environment:
- CASSANDRA_PASSWORD_SEEDER=yes
- CASSANDRA_PASSWORD=password123
```
#### Step 1: Create a new network
```console
docker network create cassandra_network
```
#### Step 2: Create a first node
```console
docker run --name cassandra-node1 \
--net=cassandra_network \
-p 9042:9042 \
-e CASSANDRA_CLUSTER_NAME=cassandra-cluster \
-e CASSANDRA_SEEDS=cassandra-node1,cassandra-node2 \
-e CASSANDRA_PASSWORD_SEEDER=yes \
-e CASSANDRA_PASSWORD=mypassword \
bitnami/cassandra:latest
```
In the above command the container is added to a cluster named `cassandra-cluster` using the `CASSANDRA_CLUSTER_NAME`. The `CASSANDRA_CLUSTER_HOSTS` parameter set the name of the nodes that set the cluster so we will need to launch other container for the second node. Finally the `CASSANDRA_NODE_NAME` parameter allows to indicate a known name for the node, otherwise cassandra will generate a random one.
#### Step 3: Create a second node
```console
docker run --name cassandra-node2 \
--net=cassandra_network \
-e CASSANDRA_CLUSTER_NAME=cassandra-cluster \
-e CASSANDRA_SEEDS=cassandra-node1,cassandra-node2 \
-e CASSANDRA_PASSWORD=mypassword \
bitnami/cassandra:latest
```
In the above command a new cassandra node is being added to the cassandra cluster indicated by `CASSANDRA_CLUSTER_NAME`.
You now have a two node Apache Cassandra cluster up and running which can be scaled by adding/removing nodes.
With Docker Compose the cluster configuration can be setup using:
```yaml
version: '2'
services:
cassandra-node1:
image: bitnami/cassandra:latest
environment:
- CASSANDRA_CLUSTER_NAME=cassandra-cluster
- CASSANDRA_SEEDS=cassandra-node1,cassandra-node2
- CASSANDRA_PASSWORD_SEEDER=yes
- CASSANDRA_PASSWORD=password123
cassandra-node2:
image: bitnami/cassandra:latest
environment:
- CASSANDRA_CLUSTER_NAME=cassandra-cluster
- CASSANDRA_SEEDS=cassandra-node1,cassandra-node2
- CASSANDRA_PASSWORD=password123
```
### Initializing with custom scripts
When the container is executed for the first time, it will execute the files with extensions `.sh`, `.cql` or `.cql.gz` located at `/docker-entrypoint-initdb.d` in sort'ed order by filename. This behavior can be skipped by setting the environment variable `CASSANDRA_IGNORE_INITDB_SCRIPTS` to a value other than `yes` or `true`.
In order to have your custom files inside the docker image you can mount them as a volume.
```console
docker run --name cassandra \
-v /path/to/init-scripts:/docker-entrypoint-initdb.d \
-v /path/to/cassandra-persistence:/bitnami
bitnami/cassandra:latest
```
Or with docker-compose
```yaml
cassandra:
image: bitnami/cassandra:latest
volumes:
- /path/to/init-scripts:/docker-entrypoint-initdb.d
- /path/to/cassandra-persistence:/bitnami
```
### Configuration file
The image looks for configurations in `/bitnami/cassandra/conf/`. As mentioned in [Persisting your application](#persisting-your-application) you can mount a volume at `/bitnami` and copy/edit the configurations in the `/path/to/cassandra-persistence/cassandra/conf/`. The default configurations will be populated to the `conf/` directory if it's empty.
#### Step 1: Run the Apache Cassandra image
Run the Apache Cassandra image, mounting a directory from your host.
```console
docker run --name cassandra \
-v /path/to/cassandra-persistence:/bitnami \
bitnami/cassandra:latest
```
or using Docker Compose:
```yaml
cassandra:
image: bitnami/cassandra:latest
volumes:
- /path/to/cassandra-persistence:/bitnami
```
#### Step 2: Edit the configuration
Edit the configuration on your host using your favorite editor.
```console
vi /path/to/cassandra-persistence/cassandra/conf/cassandra.yaml
```
#### Step 3: Restart Apache Cassandra
After changing the configuration, restart your Apache Cassandra container for changes to take effect.
```console
docker restart cassandra
```
or using Docker Compose:
```console
docker-compose restart cassandra
```
Refer to the [configuration](http://docs.datastax.com/en/cassandra/3.x/cassandra/configuration/configTOC.html) manual for the complete list of configuration options.
## TLS Encryption
The Bitnami Apache Cassandra Docker image allows configuring TLS encryption between nodes and between server-client. This is done by mounting in `/bitnami/cassandra/secrets` two files:
* `keystore`: File with the server keystore
* `truststore`: File with the server truststore
Apart from that, the following environment variables must be set:
* `CASSANDRA_KEYSTORE_PASSWORD`: Password for accessing the keystore.
* `CASSANDRA_TRUSTSTORE_PASSWORD`: Password for accessing the truststore.
* `CASSANDRA_INTERNODE_ENCRYPTION`: Sets the type of encryption between nodes. The default value is `none`. Can be set to `all`, `none`, `dc` or `rack`.
* `CASSANDRA_CLIENT_ENCRYPTION`: Enables client-server encryption. The default value is `false`.
## Logging
The Bitnami Apache Cassandra Docker image sends the container logs to the `stdout`. To view the logs:
```console
docker logs cassandra
```
or using Docker Compose:
```console
docker-compose logs cassandra
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of Apache Cassandra, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/cassandra:latest
```
or if you're using Docker Compose, update the value of the image property to
`bitnami/cassandra:latest`.
#### Step 2: Stop and backup the currently running container
Stop the currently running container using the command
```console
docker stop cassandra
```
or using Docker Compose:
```console
docker-compose stop cassandra
```
Next, take a snapshot of the persistent volume `/path/to/cassandra-persistence` using:
```console
rsync -a /path/to/cassandra-persistence /path/to/cassandra-persistence.bkp.$(date +%Y%m%d-%H.%M.%S)
```
#### Step 3: Remove the currently running container
```console
docker rm -v cassandra
```
or using Docker Compose:
```console
docker-compose rm -v cassandra
```
#### Step 4: Run the new image
Re-create your container from the new image.
```console
docker run --name cassandra bitnami/cassandra:latest
```
or using Docker Compose:
```console
docker-compose up cassandra
```
## Notable Changes
## 3.11.10-debian-10-r81 Split branch 3
* Branch 3 has been split into branch 3.0 and 3.11 mirroring the upstream Apache Cassandra repo.
### 3.11.4-debian-9-r188 and 3.11.4-ol-7-r201
* Decrease the size of the container. The configuration logic is now based on Bash scripts in the `rootfs/` folder.
### 3.11.3-r129
-The Apache Cassandra container now adds the possibility to inject custom initialization scripts by mounting cql and sh files in `/docker-entrypoint-initdb.d`. See [this section](#initializing-with-custom-scripts) for more information.
### 3.11.2-r22
* The Apache Cassandra container has been migrated to a non-root user approach. Previously the container ran as the `root` user and the Apache Cassandra daemon was started as the `cassandra` user. From now on, both the container and the Apache Cassandra daemon run as user `1001`. As a consequence, the data directory must be writable by that user. You can revert this behavior by changing `USER 1001` to `USER root` in the Dockerfile.
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/cassandra).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues), or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

80
bitnami/cert-manager/1/debian-12/README.md
View File

@@ -1,80 +0,0 @@
# Bitnami package for cert-manager
## What is cert-manager?
> cert-manager is a Kubernetes add-on to automate the management and issuance of TLS certificates from various issuing sources.
> Cert-manager is a Kubernetes add-on to automate the management and issuance of TLS certificates from various issuing sources.
[Overview of cert-manager](https://github.com/jetstack/cert-manager)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run --name cert-manager -e ALLOW_EMPTY_PASSWORD=yes bitnami/cert-manager:latest
```
**Warning**: These quick setups are only intended for development environments. You are encouraged to change the insecure default credentials and check out the available configuration options in the [Configuration](#configuration) section for a more secure deployment.
## Pre-requisites
Kubernetes cluster with `CustomResourceDefinition` or `ThirdPartyResource support`
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use cert-manager in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Configuration
### Further documentation
For further documentation, please check [here](https://github.com/jetstack/cert-manager/blob/master/docs)
## Notable Changes
### Starting January 16, 2024
* The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes.
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

113
bitnami/dremio/25/debian-12/README.md
View File

@@ -1,113 +0,0 @@
# Bitnami package for Dremio
## What is Dremio?
> Dremio is an open-source self-service data access tool that provides high-performance queries for interactive analytics on data lakes.
[Overview of Dremio](https://www.dremio.com/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run -it --name dremio bitnami/dremio
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Dremio in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Dremio Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/dremio).
```console
docker pull bitnami/dremio:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/dremio/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/dremio:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of Dremio, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/dremio:latest
```
or if you're using Docker Compose, update the value of the image property to `bitnami/dremio:latest`.
#### Step 2: Remove the currently running container
```console
docker rm -v dremio
```
#### Step 3: Run the new image
Re-create your container from the new image.
```console
docker run --name dremio bitnami/dremio:latest
```
## Configuration
### Configuration variables
This container supports the upstream Dremio environment variables. Check the [official Dremio documentation](https://www.dremio.com//dremio-latest/configuration/) for the possible environment variables.
## Contributing
We'd love for you to contribute to this Docker image. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

542
bitnami/ghost/5/debian-12/README.md
View File

@@ -1,542 +0,0 @@
# Bitnami package for Ghost
## What is Ghost?
> Ghost is an open source publishing platform designed to create blogs, magazines, and news sites. It includes a simple markdown editor with preview, theming, and SEO built-in to simplify editing.
[Overview of Ghost](https://ghost.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run --name ghost bitnami/ghost:latest
```
**Warning**: This quick setup is only intended for development environments. You are encouraged to change the insecure default credentials and check out the available configuration options in the [Environment Variables](#environment-variables) section for a more secure d
eployment.
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Ghost in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## How to deploy Ghost in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami Ghost Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/ghost).
Bitnami containers can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Ghost Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/ghost).
```console
docker pull bitnami/ghost:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/ghost/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/ghost:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## How to use this image
Ghost requires access to a MySQL or MariaDB database to store information. We'll use the [Bitnami Docker Image for MySQL](https://github.com/bitnami/containers/tree/main/bitnami/mysql) for the database requirements.
### Using the Docker Command Line
#### Step 1: Create a network
```console
docker network create ghost-network
```
#### Step 2: Create a volume for MySQL persistence and create a MySQL container
```console
$ docker volume create --name mysql_data
docker run -d --name mysql \
--env ALLOW_EMPTY_PASSWORD=yes \
--env MYSQL_USER=bn_ghost \
--env MYSQL_PASSWORD=bitnami \
--env MYSQL_DATABASE=bitnami_ghost \
--network ghost-network \
--volume mysql_data:/bitnami/mysql \
bitnami/mysql:latest
```
#### Step 3: Create volumes for Ghost persistence and launch the container
```console
$ docker volume create --name ghost_data
docker run -d --name ghost \
-p 8080:8080 -p 8443:8443 \
--env ALLOW_EMPTY_PASSWORD=yes \
--env GHOST_DATABASE_USER=bn_ghost \
--env GHOST_DATABASE_PASSWORD=bitnami \
--env GHOST_DATABASE_NAME=bitnami_ghost \
--network ghost-network \
--volume ghost_data:/bitnami/ghost \
bitnami/ghost:latest
```
Access your application at `http://your-ip/`
### Run the application using Docker Compose
```console
curl -sSL https://raw.githubusercontent.com/bitnami/containers/main/bitnami/ghost/docker-compose.yml > docker-compose.yml
docker-compose up -d
```
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/ghost).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Persisting your application
If you remove the container all your data will be lost, and the next time you run the image the database will be reinitialized. To avoid this loss of data, you should mount a volume that will persist even after the container is removed.
For persistence you should mount a directory at the `/bitnami/ghost` path. If the mounted directory is empty, it will be initialized on the first run. Additionally you should [mount a volume for persistence of the MySQL data](https://github.com/bitnami/containers/blob/main/bitnami/mysql#persisting-your-database).
The above examples define the Docker volumes named `mysql_data` and `ghost_data`. The Ghost application state will persist as long as volumes are not removed.
To avoid inadvertent removal of volumes, you can [mount host directories as data volumes](https://docs.docker.com/engine/tutorials/dockervolumes/). Alternatively you can make use of volume plugins to host the volume data.
### Mount host directories as data volumes with Docker Compose
This requires a minor change to the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/ghost/docker-compose.yml) file present in this repository:
```diff
mysql:
...
volumes:
- - 'mysql_data:/bitnami/mysql'
+ - /path/to/mysql-persistence:/bitnami/mysql
...
ghost:
...
volumes:
- - 'ghost_data:/bitnami/ghost'
+ - /path/to/ghost-persistence:/bitnami/ghost
...
-volumes:
- mysql_data:
- driver: local
- ghost_data:
- driver: local
```
> NOTE: As this is a non-root container, the mounted files and directories must have the proper permissions for the UID `1001`.
### Mount host directories as data volumes using the Docker command line
#### Step 1: Create a network (if it does not exist)
```console
docker network create ghost-network
```
#### Step 2. Create a MySQL container with host volume
```console
docker run -d --name mysql \
--env ALLOW_EMPTY_PASSWORD=yes \
--env MYSQL_USER=bn_ghost \
--env MYSQL_PASSWORD=bitnami \
--env MYSQL_DATABASE=bitnami_ghost \
--network ghost-network \
--volume /path/to/mysql-persistence:/bitnami/mysql \
bitnami/mysql:latest
```
#### Step 3. Create the Ghost container with host volumes
```console
docker run -d --name ghost \
-p 8080:8080 -p 8443:8443 \
--env ALLOW_EMPTY_PASSWORD=yes \
--env GHOST_DATABASE_USER=bn_ghost \
--env GHOST_DATABASE_PASSWORD=bitnami \
--env GHOST_DATABASE_NAME=bitnami_ghost \
--network ghost-network \
--volume /path/to/ghost-persistence:/bitnami/ghost \
bitnami/ghost:latest
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|------------------------------------|-----------------------------------------------------------------------------------------------------------------------------|----------------------------------|
| `GHOST_DATA_TO_PERSIST` | Files to persist relative to the Ghost installation directory. To provide multiple values, separate them with a whitespace. | `content config.production.json` |
| `GHOST_ENABLE_HTTPS` | Whether to enable HTTPS for Ghost by default. | `no` |
| `GHOST_EXTERNAL_HTTP_PORT_NUMBER` | External HTTP port for Ghost. | `80` |
| `GHOST_EXTERNAL_HTTPS_PORT_NUMBER` | External HTTPS port for Ghost. | `443` |
| `GHOST_HOST` | Ghost host name. | `localhost` |
| `GHOST_PORT_NUMBER` | Port number in which Ghost will run. | `nil` |
| `GHOST_BLOG_TITLE` | Ghost blog title. | `"User's blog"` |
| `GHOST_SKIP_BOOTSTRAP` | Whether to perform initial bootstrapping for the application. | `nil` |
| `GHOST_USERNAME` | Ghost user name. | `user` |
| `GHOST_PASSWORD` | Ghost user password. | `bitnami123` |
| `GHOST_EMAIL` | Ghost user e-mail address. | `user@example.com` |
| `GHOST_SMTP_FROM_ADDRESS` | Ghost SMTP from address. | `nil` |
| `GHOST_SMTP_HOST` | Ghost SMTP server host. | `nil` |
| `GHOST_SMTP_PORT_NUMBER` | Ghost SMTP server port number. | `nil` |
| `GHOST_SMTP_USER` | Ghost SMTP server user. | `nil` |
| `GHOST_SMTP_PASSWORD` | Ghost SMTP server user password. | `nil` |
| `GHOST_SMTP_PROTOCOL` | Ghost SMTP server protocol to use. | `nil` |
| `GHOST_DATABASE_HOST` | Database server host. | `$GHOST_DEFAULT_DATABASE_HOST` |
| `GHOST_DATABASE_PORT_NUMBER` | Database server port. | `3306` |
| `GHOST_DATABASE_NAME` | Database name. | `bitnami_ghost` |
| `GHOST_DATABASE_USER` | Database user name. | `bn_ghost` |
| `GHOST_DATABASE_PASSWORD` | Database user password. | `nil` |
| `GHOST_DATABASE_ENABLE_SSL` | Whether to enable SSL for database connection | `no` |
| `GHOST_DATABASE_SSL_CA_FILE` | Path to the database SSL CA file | `nil` |
#### Read-only environment variables
| Name | Description | Value |
|-------------------------------|----------------------------------------------------|--------------------------------------------|
| `GHOST_BASE_DIR` | Ghost installation directory. | `${BITNAMI_ROOT_DIR}/ghost` |
| `GHOST_BIN_DIR` | Ghost bin directory. | `${GHOST_BASE_DIR}/bin` |
| `GHOST_LOG_FILE` | Ghost log file. | `${GHOST_BASE_DIR}/content/logs/ghost.log` |
| `GHOST_CONF_FILE` | Configuration file for Ghost. | `${GHOST_BASE_DIR}/config.production.json` |
| `GHOST_PID_FILE` | Path to the Ghost PID file. | `${GHOST_BASE_DIR}/.ghostpid` |
| `GHOST_VOLUME_DIR` | Ghost directory for mounted configuration files. | `${BITNAMI_VOLUME_DIR}/ghost` |
| `GHOST_DAEMON_USER` | Ghost system user. | `ghost` |
| `GHOST_DAEMON_GROUP` | Ghost system group. | `ghost` |
| `GHOST_DEFAULT_PORT_NUMBER` | Default Ghost port number to enable at build time. | `2368` |
| `GHOST_DEFAULT_DATABASE_HOST` | Default database server host. | `mysql` |
When you start the Ghost image, you can adjust the configuration of the instance by passing one or more environment variables either on the docker-compose file or on the `docker run` command line. If you want to add a new environment variable:
* For docker-compose add the variable name and value under the application section in the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/ghost/docker-compose.yml) file present in this repository:
```yaml
ghost:
...
environment:
- GHOST_PASSWORD=my_password
...
```
* For manual execution add a `--env` option with each variable and value:
```console
$ docker run -d --name ghost -p 80:8080 -p 443:8443 \
--env GHOST_PASSWORD=my_password \
--network ghost-tier \
--volume /path/to/ghost-persistence:/bitnami/ghost \
bitnami/ghost:latest
```
#### Examples
##### SMTP configuration using a Gmail account
This would be an example of SMTP configuration using a Gmail account:
* Modify the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/ghost/docker-compose.yml) file present in this repository:
```yaml
ghost:
...
environment:
- GHOST_DATABASE_USER=bn_ghost
- GHOST_DATABASE_NAME=bitnami_ghost
- ALLOW_EMPTY_PASSWORD=yes
- GHOST_SMTP_HOST=smtp.gmail.com
- GHOST_SMTP_PORT=587
- GHOST_SMTP_USER=your_email@gmail.com
- GHOST_SMTP_PASSWORD=your_password
- GHOST_SMTP_FROM_ADDRESS=ghost@blog.com
...
```
* For manual execution:
```console
$ docker run -d --name ghost -p 80:8080 -p 443:8443 \
--env GHOST_DATABASE_USER=bn_ghost \
--env GHOST_DATABASE_NAME=bitnami_ghost \
--env GHOST_SMTP_HOST=smtp.gmail.com \
--env GHOST_SMTP_PORT=587 \
--env GHOST_SMTP_USER=your_email@gmail.com \
--env GHOST_SMTP_PASSWORD=your_password \
--env GHOST_SMTP_FROM_ADDRESS=ghost@blog.com \
--network ghost-tier \
--volume /path/to/ghost-persistence:/bitnami \
bitnami/ghost:latest
```
##### Connect Ghost container to an existing database
The Bitnami Ghost container supports connecting the Ghost application to an external database. This would be an example of using an external database for Ghost.
* Modify the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/ghost/docker-compose.yml) file present in this repository:
```diff
ghost:
...
environment:
- - GHOST_DATABASE_HOST=mysql
+ - GHOST_DATABASE_HOST=mysql_host
- GHOST_DATABASE_PORT_NUMBER=3306
- GHOST_DATABASE_NAME=ghost_db
- GHOST_DATABASE_USER=ghost_user
- - ALLOW_EMPTY_PASSWORD=yes
+ - GHOST_DATABASE_PASSWORD=ghost_password
...
```
* For manual execution:
```console
$ docker run -d --name ghost\
-p 8080:8080 -p 8443:8443 \
--network ghost-network \
--env GHOST_DATABASE_HOST=mysql_host \
--env GHOST_DATABASE_PORT_NUMBER=3306 \
--env GHOST_DATABASE_NAME=ghost_db \
--env GHOST_DATABASE_USER=ghost_user \
--env GHOST_DATABASE_PASSWORD=ghost_password \
--volume ghost_data:/bitnami/ghost \
bitnami/ghost:latest
```
In case the database already contains data from a previous Ghost installation, you need to set the variable `GHOST_SKIP_BOOTSTRAP` to `yes`. Otherwise, the container would execute the installation wizard and could modify the existing data in the database. Note that, when setting `GHOST_SKIP_BOOTSTRAP` to `yes`, values for environment variables such as `GHOST_USERNAME`, `GHOST_PASSWORD` or `GHOST_EMAIL` will be ignored.
## Logging
The Bitnami Ghost Docker image sends the container logs to `stdout`. To view the logs:
```console
docker logs ghost
```
Or using Docker Compose:
```console
docker-compose logs ghost
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Maintenance
### Backing up your container
To backup your data, configuration and logs, follow these simple steps:
#### Step 1: Stop the currently running container
```console
docker stop ghost
```
Or using Docker Compose:
```console
docker-compose stop ghost
```
#### Step 2: Run the backup command
We need to mount two volumes in a container we will use to create the backup: a directory on your host to store the backup in, and the volumes from the container we just stopped so we can access the data.
```console
docker run --rm -v /path/to/ghost-backups:/backups --volumes-from ghost busybox \
cp -a /bitnami/ghost /backups/latest
```
### Restoring a backup
Restoring a backup is as simple as mounting the backup as volumes in the containers.
For the MySQL database container:
```diff
$ docker run -d --name mysql \
...
- --volume /path/to/mysql-persistence:/bitnami/mysql \
+ --volume /path/to/mysql-backups/latest:/bitnami/mysql \
bitnami/mysql:latest
```
For the Ghost container:
```diff
$ docker run -d --name ghost \
...
- --volume /path/to/ghost-persistence:/bitnami/ghost \
+ --volume /path/to/ghost-backups/latest:/bitnami/ghost \
bitnami/ghost:latest
```
### Upgrade this image
Bitnami provides up-to-date versions of MySQL and Ghost, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container. We will cover here the upgrade of the Ghost container. For the MySQL upgrade see: <https://github.com/bitnami/containers/blob/main/bitnami/mysql/README.md#upgrade-this-image>
The `bitnami/ghost:latest` tag always points to the most recent release. To get the most recent release you can simple repull the `latest` tag from the Docker Hub with `docker pull bitnami/ghost:latest`. However it is recommended to use [tagged versions](https://hub.docker.com/r/bitnami/ghost/tags/).
#### Step 1: Get the updated image
```console
docker pull bitnami/ghost:latest
```
#### Step 2: Stop the running container
Stop the currently running container using the command
```console
docker-compose stop ghost
```
#### Step 3: Take a snapshot of the application state
Follow the steps in [Backing up your container](#backing-up-your-container) to take a snapshot of the current application state.
#### Step 4: Remove the currently running container
Remove the currently running container by executing the following command:
```console
docker-compose rm -v ghost
```
#### Step 5: Run the new image
Update the image tag in `docker-compose.yml` and re-create your container with the new image:
```console
docker-compose up -d
```
## Customize this image
The Bitnami Ghost Docker image is designed to be extended so it can be used as the base image for your custom web applications.
### Extend this image
To do so, create your own image using a Dockerfile with the format below:
```Dockerfile
FROM bitnami/ghost
## Put your customizations below
...
```
This example shows how to install the [Storage Adapter for S3](https://github.com/colinmeinke/ghost-storage-adapter-s3#ghost-storage-adapter-s3).
```Dockerfile
FROM bitnami/ghost:latest
## Change user to perform privileged actions
USER root
COPY post_ghost_config.sh /
RUN mkdir -p /.npm \
&& chmod -R g+rwX,o+rw /.npm \
&& chmod +x /post_ghost_config.sh \
&& cp /opt/bitnami/scripts/ghost/entrypoint.sh /tmp/entrypoint.sh \
&& sed '/info "\*\* Ghost setup finished! \*\*"/ a . /post_ghost_config.sh' /tmp/entrypoint.sh > /opt/bitnami/scripts/ghost/entrypoint.sh
ENV AWS_ACCESS_KEY_ID="AWS_ACCESS_KEY_ID" \
AWS_ACCESS_SECRET_KEY="AWS_ACCESS_SECRET_KEY" \
AWS_REGION="AWS_REGION" \
AWS_BUCKET="AWS_BUCKET"
## Revert to the original non-root user
USER 1001
RUN cd /bitnami/ghost \
&& npm i --silent ghost-storage-adapter-s3 \
&& mkdir -p /opt/bitnami/ghost/content/adapters/storage/s3 \
&& cp -r ./node_modules/ghost-storage-adapter-s3/* /opt/bitnami/ghost/content/adapters/storage/s3/
```
1. Prepare npm and install an adapter.
2. Add configuration for the adapter.
#### Create a script named `post_ghost_config.sh` using `jq` for adding configuration to the `config.production.json`
```console
#!/bin/bash -e
cp /opt/bitnami/ghost/config.production.json /tmp/config.tmp.json
jq -r --arg keyId $AWS_ACCESS_KEY_ID --arg accessKey $AWS_ACCESS_SECRET_KEY --arg region $AWS_REGION --arg bucket $AWS_BUCKET \
'. + { storage: { active: "s3", s3: { accessKeyId: $keyId, secretAccessKey: $accessKey, region: $region, bucket: $bucket } } }' \
/tmp/config.tmp.json > /opt/bitnami/ghost/config.production.json
```
**Add it to the `app-entrypoint.sh` just after ghost is configured.**
Finally, build the container and set the required environment variables to configure the adapter.
## Notable Changes
### 3.42.5-debian-10-r67 and 4.8.4-debian-10-r7
* The size of the container image has been decreased.
* The configuration logic is now based on Bash scripts in the *rootfs/* folder.
* It is now possible to import existing Ghost databases from other installations. In order to do this, use the environment variable `GHOST_SKIP_BOOTSTRAP`, which forces the container not to run the initial Ghost setup wizard.
### 0.11.10-r2
* The ghost container has been migrated to a non-root container approach. Previously the container run as `root` user and the ghost daemon was started as `ghost` user. From now own, both the container and the ghost daemon run as user `1001`. As a consequence, the configuration files are writable by the user running the ghost process.
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

369
bitnami/gitea/1/debian-12/README.md
View File

@@ -1,369 +0,0 @@
# Bitnami package for Gitea
## What is Gitea?
> Gitea is a lightweight code hosting solution. Written in Go, features low resource consumption, easy upgrades and multiple databases.
[Overview of Gitea](https://gitea.io/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run --name gitea bitnami/gitea:latest
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Gitea in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## How to deploy Gitea in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami Gitea Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/gitea).
Bitnami containers can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Gitea Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/gitea).
```console
docker pull bitnami/gitea:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/gitea/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/gitea:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Persisting your application
If you remove the container all your data will be lost, and the next time you run the image the database will be reinitialized. To avoid this loss of data, you should mount a volume that will persist even after the container is removed.
For persistence you should mount a directory at the `/bitnami/gitea` path. If the mounted directory is empty, it will be initialized on the first run.
```console
docker run \
--volume /path/to/gitea-persistence:/bitnami/gitea \
--env ALLOM_EMPTY_PASSWORD=false \
bitnami/gitea:latest
```
You can also do this with a minor change to the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/gitea/docker-compose.yml) file present in this repository:
```console
gitea:
...
volumes:
- /path/to/gitea-persistence:/bitnami/gitea
...
```
## Connecting to other containers
Using [Docker container networking](https://docs.docker.com/engine/userguide/networking/), a different server running inside a container can easily be accessed by your application containers and vice-versa.
Containers attached to the same network can communicate with each other using the container name as the hostname.
### Using the Command Line
In this example, we will create a Gitea client instance that will connect to the server instance that is running on the same docker network as the client.
#### Step 1: Create a network
```console
docker network create my-network --driver bridge
```
#### Step 2: Launch the Gitea container within your network
Use the `--network <NETWORK>` argument to the `docker run` command to attach the container to the `my-network` network.
```console
docker run -d --name gitea-server \
--network my-network \
--env ALLOW_EMPTY_PASSWORD=yes \
bitnami/gitea:latest
```
#### Step 3: Launch your Gitea client instance
Finally we create a new container instance to launch the Gitea client and connect to the server created in the previous step:
```console
docker run -it --rm \
--network my-network \
bitnami/gitea:latest gitea-client --host gitea-server
```
### Using a Docker Compose file
When not specified, Docker Compose automatically sets up a new network and attaches all deployed services to that network. However, we will explicitly define a new `bridge` network named `my-network`. In this example we assume that you want to connect to the Gitea server from your own custom application image which is identified in the following snippet by the service name `myapp`.
```yaml
version: '2'
networks:
my-network:
driver: bridge
services:
gitea:
image: bitnami/gitea:latest
environment:
- ALLOW_EMPTY_PASSWORD=no
networks:
- my-network
myapp:
image: 'YOUR_APPLICATION_IMAGE'
networks:
- my-network
```
> **IMPORTANT**:
>
> 1. Please update the `YOUR_APPLICATION_IMAGE` placeholder in the above snippet with your application image
> 2. In your application container, use the hostname `gitea` to connect to the Gitea server
Launch the containers using:
```console
docker-compose up -d
```
## Configuration
Gitea can be configured via environment variables or using a configuration file (`app.ini`). If a configuration option is not specified in either the configuration file or in an environment variable, Gitea uses its internal default configuration.
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|-------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| `GITEA_REPO_ROOT_PATH` | Gitea git repositories path. | `${GITEA_DATA_DIR}/git/repositories` |
| `GITEA_LFS_ROOT_PATH` | Gitea git LFS path. | `nil` |
| `GITEA_LOG_ROOT_PATH` | Gitea log path. | `${GITEA_TMP_DIR}/log` |
| `GITEA_LOG_MODE` | Gitea log mode. | `nil` |
| `GITEA_LOG_ROUTER` | Gitea log router. | `nil` |
| `GITEA_ADMIN_USER` | Admin username. | `bn_user` |
| `GITEA_ADMIN_PASSWORD` | Admin password. | `bitnami` |
| `GITEA_ADMIN_EMAIL` | Admin user email. | `user@bitnami.org` |
| `GITEA_APP_NAME` | Application name, used in the page title | `Gitea: Git with a cup of tea` |
| `GITEA_RUN_MODE` | Application run mode, affects performance and debugging. Either "dev", "prod" or "test". | `prod` |
| `GITEA_DOMAIN` | Domain name of this server. | `localhost` |
| `GITEA_SSH_DOMAIN` | Domain name of this server, used for displayed clone URL. | `${GITEA_DOMAIN}` |
| `GITEA_SSH_LISTEN_PORT` | Port for the built-in SSH server. | `2222` |
| `GITEA_SSH_PORT` | SSH port displayed in clone URL. | `${GITEA_SSH_LISTEN_PORT}` |
| `GITEA_HTTP_PORT` | Gitea HTTP listen port | `3000` |
| `GITEA_PROTOCOL` | [http, https, fcgi, http+unix, fcgi+unix] | `http` |
| `GITEA_ROOT_URL` | Overwrite the automatically generated public URL. This is useful if the internal and the external URL don't match | `${GITEA_PROTOCOL}://${GITEA_DOMAIN}:${GITEA_HTTP_PORT}` |
| `GITEA_PASSWORD_HASH_ALGO` | The hash algorithm to use [argon2, pbkdf2, scrypt, bcrypt], argon2 will spend more memory than others. | `pbkdf2` |
| `GITEA_LFS_START_SERVER` | Enables Git LFS support | `false` |
| `GITEA_ENABLE_OPENID_SIGNIN` | Enable OpenID sign-in. | `false` |
| `GITEA_ENABLE_OPENID_SIGNUP` | Enable OpenID sign-up. | `false` |
| `GITEA_DATABASE_TYPE` | The database type in use [mysql, postgres]. | `postgres` |
| `GITEA_DATABASE_HOST` | Database host address. | `postgresql` |
| `GITEA_DATABASE_PORT_NUMBER` | Database host port. | `5432` |
| `GITEA_DATABASE_NAME` | Database name. | `bitnami_gitea` |
| `GITEA_DATABASE_USERNAME` | Database username. | `bn_gitea` |
| `GITEA_DATABASE_PASSWORD` | Database password. | `nil` |
| `GITEA_DATABASE_SSL_MODE` | Database SSL mode. | `disable` |
| `GITEA_DATABASE_SCHEMA` | Database Schema. | `nil` |
| `GITEA_DATABASE_CHARSET` | Database character set. | `utf8` |
| `GITEA_SMTP_ENABLED` | Enable to use a mail service. | `false` |
| `GITEA_SMTP_HOST` | SMTP mail host address (example: smtp.gitea.io). | `nil` |
| `GITEA_SMTP_PORT` | SMTP mail port (example: 587). | `nil` |
| `GITEA_SMTP_FROM` | Mail from address, RFC 5322. This can be just an email address, or the "Name" email@example.com format. | `nil` |
| `GITEA_SMTP_USER` | Username of mailing user (usually the senders e-mail address). | `nil` |
| `GITEA_SMTP_PASSWORD` | Password of mailing user. Use "your password" for quoting if you use special characters in the password. | `nil` |
| `GITEA_OAUTH2_CLIENT_AUTO_REGISTRATION_ENABLED` | Password of mailing user. Use "your password" for quoting if you use special characters in the password. | `false` |
| `GITEA_OAUTH2_CLIENT_USERNAME` | Password of mailing user. Use "your password" for quoting if you use special characters in the password. | `nickname` |
#### Read-only environment variables
| Name | Description | Value |
|-------------------------|-----------------------------------------------------------------------------------------------------------------------------|-------------------------------|
| `GITEA_BASE_DIR` | Gitea installation directory. | `${BITNAMI_ROOT_DIR}/gitea` |
| `GITEA_WORK_DIR` | Gitea installation directory. | `${GITEA_BASE_DIR}` |
| `GITEA_CUSTOM_DIR` | Gitea configuration directory. | `${GITEA_BASE_DIR}/custom` |
| `GITEA_TMP_DIR` | Gitea TEMP directory. | `${GITEA_BASE_DIR}/tmp` |
| `GITEA_DATA_DIR` | Gitea data directory. | `${GITEA_WORK_DIR}/data` |
| `GITEA_CONF_DIR` | Gitea configuration directory. | `${GITEA_CUSTOM_DIR}/conf` |
| `GITEA_CONF_FILE` | Gitea configuration file. | `${GITEA_CONF_DIR}/app.ini` |
| `GITEA_PID_FILE` | Gitea PID file. | `${GITEA_TMP_DIR}/gitea.pid` |
| `GITEA_VOLUME_DIR` | Gitea directory for mounted configuration files. | `${BITNAMI_VOLUME_DIR}/gitea` |
| `GITEA_DATA_TO_PERSIST` | Files to persist relative to the Gitea installation directory. To provide multiple values, separate them with a whitespace. | `${GITEA_CONF_FILE} data` |
| `GITEA_DAEMON_USER` | Gitea daemon system user. | `gitea` |
| `GITEA_DAEMON_GROUP` | Gitea daemon system group. | `gitea` |
### Configuration overrides
The configuration can easily be setup by mounting your own configuration overrides on the directory `/bitnami/gitea/custom/conf/app.ini`:
```console
docker run --name gitea \
--volume /path/to/override.ini:/bitnami/gitea/custom/conf/app.ini:ro \
bitnami/gitea:latest
```
or using Docker Compose:
```yaml
version: '2'
services:
gitea:
image: bitnami/gitea:latest
volumes:
- /path/to/override.ini:/bitnami/gitea/custom/conf/app.ini:ro
```
Check the [official gitea configuration documentation](https://docs.gitea.io/en-us/config-cheat-sheet/) for all the possible overrides and settings.
### Initializing a new instance
In order to have your custom files inside the docker image you can mount them as a volume.
### Setting the admin password on first run
Passing the `GITEA_ADMIN_PASSWORD` environment variable when running the image for the first time will set the password of the `GITEA_ADMIN_USER`/`GITEA_ADMIN_EMAIL` user to the value of `GITEA_ADMIN_PASSWORD`.
```console
docker run --name gitea -e GITEA_ADMIN_PASSWORD=password123 bitnami/gitea:latest
```
or by modifying the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/gitea/docker-compose.yml) file present in this repository:
```yaml
services:
gitea:
...
environment:
- GITEA_ADMIN_PASSWORD=password123
...
```
## Logging
The Bitnami Gitea Docker image sends the container logs to `stdout`. To view the logs:
```console
docker logs gitea
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of Gitea, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/gitea:latest
```
or if you're using Docker Compose, update the value of the image property to `bitnami/gitea:latest`.
#### Step 2: Stop and backup the currently running container
Stop the currently running container using the command
```console
docker stop gitea
```
or using Docker Compose:
```console
docker-compose stop gitea
```
Next, take a snapshot of the persistent volume `/path/to/gitea-persistence` using:
```console
rsync -a /path/to/gitea-persistence /path/to/gitea-persistence.bkp.$(date +%Y%m%d-%H.%M.%S)
```
#### Step 3: Remove the currently running container
```console
docker rm -v gitea
```
or using Docker Compose:
```console
docker-compose rm -v gitea
```
#### Step 4: Run the new image
Re-create your container from the new image.
```console
docker run --name gitea bitnami/gitea:latest
```
or using Docker Compose:
```console
docker-compose up gitea
```
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/gitea).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

174
bitnami/gotrue/2/debian-12/README.md
View File

@@ -1,174 +0,0 @@
# Bitnami package for GoTrue
## What is GoTrue?
> GoTrue is an API written in Golang that can handle user registration and authentication for Jamstack projects. Based on OAuth2 and JWT, fetures user signup, authentication and custom user data.
[Overview of GoTrue](https://github.com/netlify/gotrue)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run -it --name gotrue bitnami/gotrue
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use GoTrue in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami GoTrue Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/gotrue).
```console
docker pull bitnami/gotrue:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/gotrue/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/gotrue:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of GoTrue, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/gotrue:latest
```
#### Step 2: Remove the currently running container
```console
docker rm -v gotrue
```
#### Step 3: Run the new image
Re-create your container from the new image.
```console
docker run --name gotrue bitnami/gotrue:latest
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|---------------------------------------|----------------------------------------------|--------------------------------------------------------------------------------------------------------------|
| `DB_HOST` | Database host | `localhost` |
| `DB_PORT` | Database port number | `5432` |
| `DB_NAME` | Database name | `postgres` |
| `DB_USER` | Database user username | `postgres` |
| `DB_PASSWORD` | Database password | `nil` |
| `DB_SSL` | Database SSL connection enabled | `disable` |
| `GOTRUE_DB_DATABASE_URL` | Database URL | `postgresql://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}?search_path=auth&sslmode=${DB_SSL}` |
| `GOTRUE_URI_ALLOW_LIST` | | `*` |
| `GOTRUE_OPERATOR_TOKEN` | Operator token | `nil` |
| `GOTRUE_JWT_SECRET` | JWT Secret | `nil` |
| `GOTRUE_SITE_URL` | | `http://localhost:80` |
| `GOTRUE_API_PORT` | | `9999` |
| `GOTRUE_API_HOST` | | `0.0.0.0` |
| `API_EXTERNAL_URL` | The URL on which Gotrue might be accessed at | `http://localhost:9999` |
| `GOTRUE_DISABLE_SIGNUP` | | `false` |
| `GOTRUE_DB_DRIVER` | | `postgres` |
| `GOTRUE_DB_MIGRATIONS_PATH` | | `${GOTRUE_BASE_DIR}` |
| `GOTRUE_JWT_DEFAULT_GROUP_NAME` | | `authenticated` |
| `GOTRUE_JWT_ADMIN_ROLES` | | `service_role` |
| `GOTRUE_JWT_AUD` | | `authenticated` |
| `GOTRUE_JWT_EXP` | | `3600` |
| `GOTRUE_EXTERNAL_EMAIL_ENABLED` | | `true` |
| `GOTRUE_MAILER_AUTOCONFIRM` | | `true` |
| `GOTRUE_SMTP_ADMIN_EMAIL` | | `your-mail@example.com` |
| `GOTRUE_SMTP_HOST` | | `smtp.exmaple.com` |
| `GOTRUE_SMTP_PORT` | | `587` |
| `GOTRUE_SMTP_SENDER_NAME` | | `your-mail@example.com` |
| `GOTRUE_EXTERNAL_PHONE_ENABLED` | | `false` |
| `GOTRUE_SMS_AUTOCONFIRM` | | `false` |
| `GOTRUE_MAILER_URLPATHS_INVITE` | | `http://localhost:80/auth/v1/verify` |
| `GOTRUE_MAILER_URLPATHS_CONFIRMATION` | | `http://localhost:80/auth/v1/verify` |
| `GOTRUE_MAILER_URLPATHS_RECOVERY` | | `http://localhost:80/auth/v1/verify` |
| `GOTRUE_MAILER_URLPATHS_EMAIL_CHANGE` | | `http://localhost:80/auth/v1/verify` |
#### Read-only environment variables
| Name | Description | Value |
|-----------------------|------------------------------------------|---------------------------------|
| `GOTRUE_BASE_DIR` | gotrue installation directory. | `${BITNAMI_ROOT_DIR}/gotrue` |
| `GOTRUE_LOGS_DIR` | Directory where gotrue logs are stored. | `${GOTRUE_BASE_DIR}/logs` |
| `GOTRUE_LOG_FILE` | Directory where gotrue logs are stored. | `${GOTRUE_LOGS_DIR}/gotrue.log` |
| `GOTRUE_BIN_DIR` | gotrue directory for binary executables. | `${GOTRUE_BASE_DIR}/bin` |
| `GOTRUE_DAEMON_USER` | postgrest system user. | `supabase` |
| `GOTRUE_DAEMON_GROUP` | postgrest system group. | `supabase` |
### Running commands
To run commands inside this container you can use `docker run`, for example to execute `gotrue --help` you can follow the example below:
```console
docker run --rm --name gotrue bitnami/gotrue:latest --help
```
Check the [official GoTrue documentation](https://github.com/netlify/gotrue) for more information about how to use GoTrue.
## Notable Changes
### Starting January 16, 2024
* The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes.
## Contributing
We'd love for you to contribute to this Docker image. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

155
bitnami/jaeger/1/debian-12/README.md
View File

@@ -1,155 +0,0 @@
# Jaeger packaged by Bitnami
## What is jaeger?
> Jaeger is a Distributed Tracing System
[Overview of jaeger](https://www.jaegertracing.io/)
## TL;DR
```console
docker run --name jaeger bitnami/jaeger:latest
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use jaeger in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Jaeger Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/jaeger).
```console
docker pull bitnami/jaeger:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/jaeger/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/jaeger:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|---------------------------------------------|----------------------------------------------------------------------------|---------------|
| `JAEGER_USERNAME` | Jaeger username. | `user` |
| `JAEGER_PASSWORD` | Jaeger password. | `bitnami` |
| `JAEGER_AGENT_ZIPKIN_UDP_PORT_NUMBER` | Jaeger Agent UDP port. Accept zipkin.thrift over compact thrift protocol | `5775` |
| `JAEGER_AGENT_COMPACT_UDP_PORT_NUMBER` | Jaeger Agent UDP port. Accept jaeger.thrift over compact thrift protocol | `6831` |
| `JAEGER_AGENT_BINARY_UDP_PORT_NUMBER` | Jaeger Agent UDP port. Accept jaeger.thrift over binary thrift protocol | `6832` |
| `JAEGER_AGENT_HTTP_PORT_NUMBER` | Jaeger Agent HTTP port. Serve configs. | `5778` |
| `JAEGER_QUERY_HTTP_PORT_NUMBER` | Jaeger Query HTTP port. | `16686` |
| `JAEGER_QUERY_GRPC_PORT_NUMBER` | Jaeger Query GRPC port. | `16685` |
| `JAEGER_COLLECTOR_ZIPKIN_PORT_NUMBER` | Jaeger Collector Zipkin compatible port. | `nil` |
| `JAEGER_COLLECTOR_HTTP_PORT_NUMBER` | Jaeger Collector HTTP port. Accept jaeger.thrift directly from clients | `14268` |
| `JAEGER_COLLECTOR_GRPC_PORT_NUMBER` | Jaeger Collector GRPC port. Accept jaeger.thrift directly from clients | `14250` |
| `JAEGER_ADMIN_HTTP_PORT_NUMBER` | Jaeger Admin port. | `14269` |
| `JAEGER_AGENT_ZIPKIN_UDP_HOST` | Jaeger Agent UDP host. Accept zipkin.thrift over compact thrift protocol | `nil` |
| `JAEGER_AGENT_COMPACT_UDP_HOST` | Jaeger Agent UDP host. Accept jaeger.thrift over compact thrift protocol | `nil` |
| `JAEGER_AGENT_BINARY_UDP_HOST` | Jaeger Agent UDP host. Accept jaeger.thrift over binary thrift protocol | `nil` |
| `JAEGER_AGENT_HTTP_HOST` | Jaeger Agent HTTP host. Serve configs. | `nil` |
| `JAEGER_QUERY_HTTP_HOST` | Jaeger Query HTTP host. | `nil` |
| `JAEGER_QUERY_GRPC_HOST` | Jaeger Query GRPC host. | `nil` |
| `JAEGER_COLLECTOR_HTTP_HOST` | Jaeger Collector Zipkin compatible host. | `nil` |
| `JAEGER_COLLECTOR_GRPC_HOST` | Jaeger Collector HTTP host. Accept jaeger.thrift directly from clients | `nil` |
| `JAEGER_ADMIN_HTTP_HOST` | Jaeger Collector GRPC host. Accept jaeger.thrift directly from clients | `nil` |
| `JAEGER_COLLECTOR_ZIPKIN_HOST` | Jaeger Admin host. | `nil` |
| `JAEGER_APACHE_QUERY_HTTP_PORT_NUMBER` | Jaeger Query UI HTTP port, exposed via Apache with basic authentication. | `nil` |
| `JAEGER_APACHE_QUERY_HTTPS_PORT_NUMBER` | Jaeger Query UI HTTPS port, exposed via Apache with basic authentication. | `nil` |
| `JAEGER_APACHE_COLLECTOR_HTTP_PORT_NUMBER` | Jaeger Collector HTTP port, exposed via Apache with basic authentication. | `14270` |
| `JAEGER_APACHE_COLLECTOR_HTTPS_PORT_NUMBER` | Jaeger Collector HTTPS port, exposed via Apache with basic authentication. | `14271` |
| `SPAN_STORAGE_TYPE` | Jaeger storage type. | `cassandra` |
| `JAEGER_CASSANDRA_HOST` | Cassandra server host. | `127.0.0.1` |
| `JAEGER_CASSANDRA_PORT_NUMBER` | Cassandra server port. | `9042` |
| `JAEGER_CASSANDRA_KEYSPACE` | Cassandra keyspace. | `bn_jaeger` |
| `JAEGER_CASSANDRA_DATACENTER` | Cassandra keyspace. | `dc1` |
| `JAEGER_CASSANDRA_USER` | Cassandra user name. | `cassandra` |
| `JAEGER_CASSANDRA_PASSWORD` | Cassandra user password. | `nil` |
#### Read-only environment variables
| Name | Description | Value |
|-----------------------|------------------------------------|---------------------------------|
| `JAEGER_BASE_DIR` | Jaeger installation directory. | `${BITNAMI_ROOT_DIR}/jaeger` |
| `JAEGER_BIN_DIR` | Jaeger directory for binary files. | `${JAEGER_BASE_DIR}/bin` |
| `JAEGER_CONF_DIR` | Jaeger configuration directory. | `${JAEGER_BASE_DIR}/conf` |
| `JAEGER_CONF_FILE` | Jaeger configuration file. | `${JAEGER_CONF_DIR}/jaeger.yml` |
| `JAEGER_LOGS_DIR` | Jaeger logs directory. | `${JAEGER_BASE_DIR}/logs` |
| `JAEGER_LOG_FILE` | Jaeger log file. | `${JAEGER_LOGS_DIR}/jaeger.log` |
| `JAEGER_TMP_DIR` | Jaeger temporary directory. | `${JAEGER_BASE_DIR}/tmp` |
| `JAEGER_PID_FILE` | Jaeger PID file. | `${JAEGER_TMP_DIR}/jaeger.pid` |
| `JAEGER_DAEMON_USER` | Jaeger daemon system user. | `jaeger` |
| `JAEGER_DAEMON_GROUP` | Jaeger daemon system group. | `jaeger` |
### Running commands
To run commands inside this container you can use `docker run`, for example to execute `jaeger-all-in-one --help` you can follow the example below:
```console
docker run --rm --name jaeger bitnami/jaeger:latest --help
```
Check the [official jaeger documentation](https://www.jaegertracing.io//docs) for more information.
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/jaeger).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

97
bitnami/keycloak-config-cli/6/debian-12/README.md
View File

@@ -1,97 +0,0 @@
# Bitnami package for Keycloak Config CLI
## What is Keycloak Config CLI?
> keycloak-config-cli is a Keycloak extension to import JSON or YAML configuration into the Keycloak server without restarting it.
[Overview of Keycloak Config CLI](https://github.com/adorsys/keycloak-config-cli)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run --rm --name keycloak-config-cli bitnami/keycloak-config-cli:latest
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Keycloak Config CLI in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## How to deploy Keycloak Config CLI in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami Keycloak Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/keycloak).
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Keycloak Config CLI Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/keycloak-config-cli).
```console
docker pull bitnami/keycloak-config-cli:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/keycloak-config-cli/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/keycloak-config-cli:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Configuration
Find how to configure Keycloak Config CLI in its [official documentation](https://github.com/adorsys/keycloak-config-cli#cli-option--environment-variables).
## Notable Changes
### Starting January 16, 2024
* The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes.
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

313
bitnami/keycloak/24/debian-12/README.md
View File

@@ -1,313 +0,0 @@
# Bitnami package for Keycloak
## What is Keycloak?
> Keycloak is a high performance Java-based identity and access management solution. It lets developers add an authentication layer to their applications with minimum effort.
[Overview of Keycloak](https://www.keycloak.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run --name keycloak bitnami/keycloak:latest
```
**Warning**: This quick setup is only intended for development environments. You are encouraged to change the insecure default credentials and check out the available configuration options in the [Configuration](#configuration) section for a more secure deployment.
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Keycloak in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## How to deploy Keycloak in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami Keycloak Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/keycloak).
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami keycloak Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/keycloak).
```console
docker pull bitnami/keycloak:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/keycloak/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/keycloak:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|-------------------------------------------------------------|-------------------------------------------------------------------------------------------------------|-------------------------------|
| `KEYCLOAK_MOUNTED_CONF_DIR` | Directory for including custom configuration files (that override the default generated ones) | `${KEYCLOAK_VOLUME_DIR}/conf` |
| `KC_RUN_IN_CONTAINER` | Keycloak kc.sh context | `true` |
| `KEYCLOAK_ADMIN` | Keycloak administrator user | `user` |
| `KEYCLOAK_ADMIN_PASSWORD` | Keycloak administrator password | `bitnami` |
| `KEYCLOAK_HTTP_RELATIVE_PATH` | Set the path relative to "/" for serving resources. | `/` |
| `KEYCLOAK_HTTP_PORT` | HTTP port | `8080` |
| `KEYCLOAK_HTTPS_PORT` | HTTPS port | `8443` |
| `KEYCLOAK_BIND_ADDRESS` | Bind address | `$(hostname --fqdn)` |
| `KEYCLOAK_HOSTNAME` | Keycloak hostname | `nil` |
| `KEYCLOAK_INIT_MAX_RETRIES` | Maximum retries for checking that the database works | `10` |
| `KEYCLOAK_CACHE_TYPE` | Defines the cache mechanism for high-availability. | `ispn` |
| `KEYCLOAK_CACHE_STACK` | Apply a specific cache stack | `nil` |
| `KEYCLOAK_CACHE_CONFIG_FILE` | Path to the cache config file | `nil` |
| `KEYCLOAK_EXTRA_ARGS` | Add extra startup parameters to keycloak | `nil` |
| `KEYCLOAK_ENABLE_STATISTICS` | Enable metrics for the database | `false` |
| `KEYCLOAK_ENABLE_HEALTH_ENDPOINTS` | Enable health endpoints | `false` |
| `KEYCLOAK_ENABLE_HTTPS` | Enable SSL certificates | `false` |
| `KEYCLOAK_HTTPS_TRUST_STORE_FILE` | Path to the SSL truststore file | `nil` |
| `KEYCLOAK_HTTPS_TRUST_STORE_PASSWORD` | Password for decrypting the truststore file | `nil` |
| `KEYCLOAK_HTTPS_KEY_STORE_FILE` | Path to the SSL keystore file | `nil` |
| `KEYCLOAK_HTTPS_KEY_STORE_PASSWORD` | Password for decrypting the keystore file | `nil` |
| `KEYCLOAK_HTTPS_USE_PEM` | Set to true to configure HTTPS using PEM certificates | `false` |
| `KEYCLOAK_HTTPS_CERTIFICATE_FILE` | Path to the PEM certificate file | `nil` |
| `KEYCLOAK_HTTPS_CERTIFICATE_KEY_FILE` | Path to the PEM key file | `nil` |
| `KEYCLOAK_SPI_TRUSTSTORE_FILE` | Path to the Keycloak SPI truststore file | `nil` |
| `KEYCLOAK_SPI_TRUSTSTORE_PASSWORD` | Password for decrypting the SPI truststore file | `nil` |
| `KEYCLOAK_SPI_TRUSTSTORE_FILE_HOSTNAME_VERIFICATION_POLICY` | Hostqname verification policy for SPI connection over HTTPS/TLS | `nil` |
| `KEYCLOAK_LOG_LEVEL` | Keycloak log level | `info` |
| `KEYCLOAK_LOG_OUTPUT` | Keycloak log output | `default` |
| `KEYCLOAK_ROOT_LOG_LEVEL` | Keycloak root log level | `INFO` |
| `KEYCLOAK_PROXY_HEADERS` | Keycloak reverse proxy headers | `nil` |
| `KEYCLOAK_PRODUCTION` | Run in production mode | `false` |
| `KEYCLOAK_EXTRA_ARGS_PREPENDED` | Run with flags which are applied directly to keycloak executable | `nil` |
| `KEYCLOAK_DATABASE_VENDOR` | Database vendor | `postgresql` |
| `KEYCLOAK_DATABASE_HOST` | Database backend hostname | `postgresql` |
| `KEYCLOAK_DATABASE_PORT` | Database backend port | `5432` |
| `KEYCLOAK_DATABASE_USER` | Database backend username | `bn_keycloak` |
| `KEYCLOAK_DATABASE_NAME` | Database name | `bitnami_keycloak` |
| `KEYCLOAK_DATABASE_PASSWORD` | Database backend password | `nil` |
| `KEYCLOAK_DATABASE_SCHEMA` | PostgreSQL database schema | `public` |
| `KEYCLOAK_JDBC_PARAMS` | Extra JDBC connection parameters for the database (e.g.: `sslmode=verify-full&connectTimeout=30000`\) | `nil` |
| `KEYCLOAK_JDBC_DRIVER` | JDBC driver to set in the connection string for the database | `postgresql` |
| `KEYCLOAK_DAEMON_USER` | Keycloak daemon user when running as root | `keycloak` |
| `KEYCLOAK_DAEMON_GROUP` | Keycloak daemon group when running as root | `keycloak` |
#### Read-only environment variables
| Name | Description | Value |
|------------------------------|---------------------------------------------------------|-----------------------------------|
| `BITNAMI_VOLUME_DIR` | Directory where to mount volumes. | `/bitnami` |
| `JAVA_HOME` | Java installation directory | `/opt/bitnami/java` |
| `KEYCLOAK_BASE_DIR` | Keycloak base directory | `/opt/bitnami/keycloak` |
| `KEYCLOAK_BIN_DIR` | Keycloak bin directory | `$KEYCLOAK_BASE_DIR/bin` |
| `KEYCLOAK_PROVIDERS_DIR` | Keycloak Wildfly extensions directory | `$KEYCLOAK_BASE_DIR/providers` |
| `KEYCLOAK_LOG_DIR` | Keycloak bin directory | `$KEYCLOAK_PROVIDERS_DIR/log` |
| `KEYCLOAK_TMP_DIR` | Keycloak tmp directory | `$KEYCLOAK_PROVIDERS_DIR/tmp` |
| `KEYCLOAK_DOMAIN_TMP_DIR` | Keycloak tmp directory | `$KEYCLOAK_BASE_DIR/domain/tmp` |
| `WILDFLY_BASE_DIR` | Wildfly base directory | `/opt/bitnami/wildfly` |
| `KEYCLOAK_VOLUME_DIR` | Path to keycloak mount directory | `/bitnami/keycloak` |
| `KEYCLOAK_CONF_DIR` | Keycloak configuration directory | `$KEYCLOAK_BASE_DIR/conf` |
| `KEYCLOAK_DEFAULT_CONF_DIR` | Keycloak default configuration directory | `$KEYCLOAK_BASE_DIR/conf.default` |
| `KEYCLOAK_INITSCRIPTS_DIR` | Path to keycloak init scripts directory | `/docker-entrypoint-initdb.d` |
| `KEYCLOAK_CONF_FILE` | Name of the keycloak configuration file (relative path) | `keycloak.conf` |
| `KEYCLOAK_DEFAULT_CONF_FILE` | Name of the keycloak configuration file (relative path) | `keycloak.conf` |
### Extra arguments to Keycloak startup
In case you want to add extra flags to the Keycloak use the `KEYCLOAK_EXTRA_ARGS` variable. Example:
```console
docker run --name keycloak \
-e KEYCLOAK_EXTRA_ARGS="-Dkeycloak.profile.feature.scripts=enabled" \
bitnami/keycloak:latest
```
Or, if you need flags which are applied directly to keycloak executable, you can use `KEYCLOAK_EXTRA_ARGS_PREPENDED` variable. Example:
```console
docker run --name keycloak \
-e KEYCLOAK_EXTRA_ARGS_PREPENDED="--spi-login-protocol-openid-connect-legacy-logout-redirect-uri=true" \
bitnami/keycloak:latest
```
### Initializing a new instance
When the container is launched, it will execute the files with extension `.sh` located at `/docker-entrypoint-initdb.d`.
In order to have your custom files inside the docker image you can mount them as a volume.
```console
docker run --name keycloak \
-v /path/to/init-scripts:/docker-entrypoint-initdb.d \
bitnami/keycloak:latest
```
Or with docker-compose
```yaml
keycloak:
image: bitnami/keycloak:latest
volumes:
- /path/to/init-scripts:/docker-entrypoint-initdb.d
```
### TLS Encryption
The Bitnami Keycloak Docker image allows configuring HTTPS/TLS encription. This is done by mounting in `/opt/bitnami/keycloak/certs` two files:
* `keystore`: File with the server keystore
* `truststore`: File with the server truststore
> Note: find more information about how to create these files at the [Keycloak documentation](https://www.keycloak.org/server/keycloak-truststore).
Apart from that, the following environment variables must be set:
* `KEYCLOAK_ENABLE_HTTPS`: Enable TLS encryption using the keystore. Default: **false**.
* `KEYCLOAK_HTTPS_KEY_STORE_FILE`: Path to the keystore file (e.g. `/opt/bitnami/keycloak/certs/keystore.jks`). No defaults.
* `KEYCLOAK_HTTPS_TRUST_STORE_FILE`: Path to the truststore file (e.g. `/opt/bitnami/keycloak/certs/truststore.jks`). No defaults.
* `KEYCLOAK_HTTPS_KEY_STORE_PASSWORD`: Password for accessing the keystore. No defaults.
* `KEYCLOAK_HTTPS_TRUST_STORE_PASSWORD`: Password for accessing the truststore. No defaults.
* `KEYCLOAK_HTTPS_USE_PEM`: Set to true to configure HTTPS using PEM certificates'. Default: **false**.
* `KEYCLOAK_HTTPS_CERTIFICATE_FILE`: Path to the PEM certificate file (e.g. `/opt/bitnami/keycloak/certs/tls.crt`). No defaults.
* `KEYCLOAK_HTTPS_CERTIFICATE_KEY_FILE`: Path to the PEM key file (e.g. `/opt/bitnami/keycloak/certs/tls.key`). No defaults.
### SPI TLS truststore
The Bitnami Keycloak Docker image supports configuring a truststore for HTTP/TLS connection with Keycloak SPIs.
* `KEYCLOAK_SPI_TRUSTSTORE_FILE`: Path to the Keycloak SPI truststore file (e.g. `/opt/bitnami/keycloak/certs-spi/truststore.jks`). No defaults.
* `KEYCLOAK_SPI_TRUSTSTORE_PASSWORD`: Password for decrypting the SPI truststore file. No defaults.
* `KEYCLOAK_SPI_TRUSTSTORE_FILE_HOSTNAME_VERIFICATION_POLICY`: Hostname verification policy for SPI connection over HTTPS/TLS
### Adding custom themes
In order to add new themes to Keycloak, you can mount them to the `/opt/bitnami/keycloak/themes` folder. The example below mounts a new theme.
```yaml
version: '2'
services:
postgresql:
image: docker.io/bitnami/postgresql:latest
environment:
- ALLOW_EMPTY_PASSWORD=yes
- POSTGRESQL_USERNAME=bn_keycloak
- POSTGRESQL_DATABASE=bitnami_keycloak
volumes:
- 'postgresql_data:/bitnami/postgresql'
keycloak:
image: docker.io/bitnami/keycloak:latest
ports:
- "80:8080"
environment:
- KEYCLOAK_CREATE_ADMIN_USER=true
depends_on:
- postgresql
volumes:
- './mynewtheme:/opt/bitnami/keycloak/themes/mynewtheme'
volumes:
postgresql_data:
driver: local
```
### Enabling statistics
The Bitnami Keycloak container can activate different set of statistics (database, jgroups and http) by setting the environment variable `KEYCLOAK_ENABLE_STATISTICS=true`.
### Enabling health endpoints
The Bitnami Keycloak container can activate several endpoints providing information about the health of Keycloak, by setting the environment variable `KEYCLOAK_ENABLE_HEALTH_ENDPOINTS=true`.
See [the official documentation](https://www.keycloak.org/server/health) for more information about these endpoints.
### Full configuration
The image looks for configuration files in the `/bitnami/keycloak/conf/` directory, this directory can be changed by setting the `KEYCLOAK_MOUNTED_CONF_DIR` environment variable.
```console
docker run --name keycloak \
-v /path/to/keycloak.conf:/bitnami/keycloak/conf/keycloak.conf \
bitnami/keycloak:latest
```
Or with docker-compose
```yaml
keycloak:
image: bitnami/keycloak:latest
volumes:
- /path/to/keycloak.conf:/bitnami/keycloak/conf/keycloak.conf:ro
```
After that, your changes will be taken into account in the server's behaviour.
## Notable Changes
### 19-debian-11-r4
* TLS environment variables have been renamed to match upstream.
* `KEYCLOAK_ENABLE_TLS` was renamed as `KEYCLOAK_ENABLE_HTTPS`.
* `KEYCLOAK_TLS_KEYSTORE_FILE` was renamed as `KEYCLOAK_TLS_KEY_STORE_FILE`.
* `KEYCLOAK_TLS_TRUSTSTORE_FILE` was renamed as `KEYCLOAK_TLS_TRUST_STORE_FILE`.
* `KEYCLOAK_TLS_KEYSTORE_PASSWORD` was renamed as `KEYCLOAK_TLS_KEY_STORE_PASSWORD`.
* `KEYCLOAK_TLS_TRUSTSTORE_PASSWORD` was renamed as `KEYCLOAK_TLS_TRUST_STORE_PASSWORD`.
* HTTPS/TLS can now be configured using PEM certificates.
* Added support to add SPI truststore file.
### 17-debian-10
Keycloak 17 is powered by Quarkus and to deploy it in production mode it is necessary to set up TLS.
To do this you need to set `KEYCLOAK_PRODUCTION` to **true** and configure TLS
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/keycloak).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

176
bitnami/minio-client/2024/debian-12/README.md
View File

@@ -1,176 +0,0 @@
# Bitnami Object Storage Client based on MinIO&reg;
## What is Bitnami Object Storage Client based on MinIO&reg;?
> MinIO&reg; Client is a Golang CLI tool that offers alternatives for ls, cp, mkdir, diff, and rsync commands for filesystems and object storage systems.
[Overview of Bitnami Object Storage Client based on MinIO&reg;](https://min.io/)
Disclaimer: All software products, projects and company names are trademark(TM) or registered(R) trademarks of their respective holders, and use of them does not imply any affiliation or endorsement. This software is licensed to you subject to one or more open source licenses and VMware provides the software on an AS-IS basis. MinIO(R) is a registered trademark of the MinIO, Inc in the US and other countries. Bitnami is not affiliated, associated, authorized, endorsed by, or in any way officially connected with MinIO Inc. MinIO(R) is licensed under GNU AGPL v3.0.
## TL;DR
```console
docker run --name minio-client bitnami/minio-client:latest
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Bitnami Object Storage Client based on MinIO&reg; in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami MinIO(R) Client Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/minio-client).
```console
docker pull bitnami/minio-client:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/minio-client/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/minio-client:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Environment variables
### Customizable environment variables
| Name | Description | Default Value |
|------------------------------|-------------------------------------------------|---------------|
| `MINIO_CLIENT_CONF_DIR` | MinIO Client directory for configuration files. | `/.mc` |
| `MINIO_SERVER_HOST` | MinIO Server host. | `nil` |
| `MINIO_SERVER_PORT_NUMBER` | MinIO Server port number. | `9000` |
| `MINIO_SERVER_SCHEME` | MinIO Server web scheme. | `http` |
| `MINIO_SERVER_ROOT_USER` | MinIO Server root user name. | `nil` |
| `MINIO_SERVER_ROOT_PASSWORD` | Password for MinIO Server root user. | `nil` |
### Read-only environment variables
| Name | Description | Value |
|-------------------------|--------------------------------------|------------------------------------|
| `MINIO_CLIENT_BASE_DIR` | MinIO Client installation directory. | `${BITNAMI_ROOT_DIR}/minio-client` |
| `MINIO_CLIENT_BIN_DIR` | MinIO Client directory for binaries. | `${MINIO_CLIENT_BASE_DIR}/bin` |
| `MINIO_DAEMON_USER` | MinIO system user. | `minio` |
| `MINIO_DAEMON_GROUP` | MinIO system group. | `minio` |
## Connecting to other containers
Using [Docker container networking](https://docs.docker.com/engine/userguide/networking/), a MinIO(R) Client can be used to access other running containers such as [MinIO(R) server](https://github.com/bitnami/containers/blob/main/bitnami/minio).
Containers attached to the same network can communicate with each other using the container name as the hostname.
### Using the Command Line
In this example, we will create a MinIO(R) Client container that will connect to a MinIO(R) server container that is running on the same docker network.
#### Step 1: Create a network
```console
docker network create app-tier --driver bridge
```
#### Step 2: Launch the MinIO(R) server container
Use the `--network app-tier` argument to the `docker run` command to attach the MinIO(R) container to the `app-tier` network.
```console
docker run -d --name minio-server \
--env MINIO_ROOT_USER="minio-root-user" \
--env MINIO_ROOT_PASSWORD="minio-root-password" \
--network app-tier \
bitnami/minio:latest
```
#### Step 3: Launch your MinIO(R) Client container
Finally we create a new container instance to launch the MinIO(R) client and connect to the server created in the previous step. In this example, we create a new bucket in the MinIO(R) storage server:
```console
docker run --rm --name minio-client \
--env MINIO_SERVER_HOST="minio-server" \
--env MINIO_SERVER_ACCESS_KEY="minio-root-user" \
--env MINIO_SERVER_SECRET_KEY="minio-root-password" \
--network app-tier \
bitnami/minio-client \
mb minio/my-bucket
```
## Configuration
MinIO(R) Client (`mc`) can be setup so it is already configured to point to a specific MinIO(R) server by providing the environment variables below:
* `MINIO_SERVER_HOST`: MinIO(R) server host.
* `MINIO_SERVER_PORT_NUMBER`: MinIO(R) server port. Default: `9000`.
* `MINIO_SERVER_SCHEME`: MinIO(R) server scheme. Default: `http`.
* `MINIO_SERVER_ACCESS_KEY`: MinIO(R) server Access Key. Must be common on every node.
* `MINIO_SERVER_SECRET_KEY`: MinIO(R) server Secret Key. Must be common on every node.
For instance, use the command below to create a new bucket in the MinIO(R) Server `my.minio.domain`:
```console
docker run --rm --name minio-client \
--env MINIO_SERVER_HOST="my.minio.domain" \
--env MINIO_SERVER_ACCESS_KEY="minio-access-key" \
--env MINIO_SERVER_SECRET_KEY="minio-secret-key" \
bitnami/minio-client \
mb minio/my-bucket
```
Find more information about the client configuration in the [MinIO(R) Client documentation](https://docs.min.io/docs/minio-admin-complete-guide.html).
## Notable Changes
### Starting January 16, 2024
* The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes.
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

554
bitnami/minio/2024/debian-12/README.md
View File

@@ -1,554 +0,0 @@
# Bitnami Object Storage based on MinIO&reg;
## What is Bitnami Object Storage based on MinIO&reg;?
> MinIO&reg; is an object storage server, compatible with Amazon S3 cloud storage service, mainly used for storing unstructured data (such as photos, videos, log files, etc.).
[Overview of Bitnami Object Storage based on MinIO&reg;](https://min.io/)
Disclaimer: All software products, projects and company names are trademark(TM) or registered(R) trademarks of their respective holders, and use of them does not imply any affiliation or endorsement. This software is licensed to you subject to one or more open source licenses and VMware provides the software on an AS-IS basis. MinIO(R) is a registered trademark of the MinIO Inc. in the US and other countries. Bitnami is not affiliated, associated, authorized, endorsed by, or in any way officially connected with MinIO Inc. MinIO(R) is licensed under GNU AGPL v3.0.
## TL;DR
```console
docker run --name minio bitnami/minio:latest
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Bitnami Object Storage based on MinIO&reg; in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## How to deploy MinIO(R) in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami MinIO(R) Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/minio).
Bitnami containers can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami MinIO(R) Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/minio).
```console
docker pull bitnami/minio:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/minio/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/minio:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Persisting your database
If you remove the container all your data will be lost, and the next time you run the image the database will be reinitialized. To avoid this loss of data, you should mount a volume that will persist even after the container is removed.
For persistence you should mount a directory at the `/bitnami/minio/data` path.
```console
docker run --name minio \
--publish 9000:9000 \
--publish 9001:9001 \
--volume /path/to/minio-persistence:/bitnami/minio/data \
bitnami/minio:latest
```
or by modifying the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/minio/docker-compose.yml) file present in this repository:
```yaml
services:
minio:
...
volumes:
- /path/to/minio-persistence:/bitnami/minio/data
...
```
You can also mount a volume to a custom path inside the container, provided that you run the container using the `MINIO_DATA_DIR` environment variable.
```console
docker run --name minio \
--publish 9000:9000 \
--publish 9001:9001 \
--volume /path/to/minio-persistence:/custom/path/within/container \
--env MINIO_DATA_DIR=/custom/path/within/container \
bitnami/minio:latest
```
or by modifying the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/minio/docker-compose.yml) file present in this repository:
```yaml
services:
minio:
...
volumes:
- /path/to/minio-persistence:/custom/path/within/container
...
environment:
- MINIO_DATA_DIR=/custom/path/within/container
...
```
> NOTE: As this is a non-root container, the mounted files and directories must have the proper permissions for the UID `1001`.
## Connecting to other containers
Using [Docker container networking](https://docs.docker.com/engine/userguide/networking/), a MinIO(R) server running inside a container can easily be accessed by your application containers.
Containers attached to the same network can communicate with each other using the container name as the hostname.
### Using the Command Line
In this example, we will create a [MinIO(R) client](https://github.com/bitnami/containers/blob/main/bitnami/minio-client) container that will connect to the server container that is running on the same docker network as the client.
#### Step 1: Create a network
```console
docker network create app-tier --driver bridge
```
#### Step 2: Launch the MinIO(R) server container
Use the `--network app-tier` argument to the `docker run` command to attach the MinIO(R) container to the `app-tier` network.
```console
docker run -d --name minio-server \
--env MINIO_ROOT_USER="minio-root-user" \
--env MINIO_ROOT_PASSWORD="minio-root-password" \
--network app-tier \
bitnami/minio:latest
```
#### Step 3: Launch your MinIO(R) Client container
Finally we create a new container instance to launch the MinIO(R) client and connect to the server created in the previous step. In this example, we create a new bucket in the MinIO(R) storage server:
```console
docker run -it --rm --name minio-client \
--env MINIO_SERVER_HOST="minio-server" \
--env MINIO_SERVER_ACCESS_KEY="minio-access-key" \
--env MINIO_SERVER_SECRET_KEY="minio-secret-key" \
--network app-tier \
bitnami/minio-client \
mb minio/my-bucket
```
### Using a Docker Compose file
When not specified, Docker Compose automatically sets up a new network and attaches all deployed services to that network. However, we will explicitly define a new `bridge` network named `app-tier`. In this example we assume that you want to connect to the MinIO(R) server from your own custom application image which is identified in the following snippet by the service name `myapp`.
```yaml
version: '2'
networks:
app-tier:
driver: bridge
services:
minio:
image: 'bitnami/minio:latest'
ports:
- '9000:9000'
- '9001:9001'
environment:
- MINIO_ROOT_USER=minio-root-user
- MINIO_ROOT_PASSWORD=minio-root-password
networks:
- app-tier
myapp:
image: 'YOUR_APPLICATION_IMAGE'
networks:
- app-tier
environment:
- MINIO_SERVER_ACCESS_KEY=minio-access-key
- MINIO_SERVER_SECRET_KEY=minio-secret-key
```
> **IMPORTANT**:
>
> 1. Please update the **YOUR_APPLICATION_IMAGE_** placeholder in the above snippet with your application image
> 2. In your application container, use the hostname `minio` to connect to the MinIO(R) server. Use the environment variables `MINIO_SERVER_ACCESS_KEY` and `MINIO_SERVER_SECRET_KEY` to configure the credentials to access the MinIO(R) server.
> 3. Make sure that the environment variables `MINIO_ROOT_PASSWORD` and `MINIO_SERVER_SECRET_KEY` meet the 8 character minimum length requirement enforced by MinIO(R).
Launch the containers using:
```console
docker-compose up -d
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|------------------------------------------|----------------------------------------------------------------------------|----------------------------------------------------|
| `MINIO_DATA_DIR` | MinIO directory for data. | `/bitnami/minio/data` |
| `MINIO_API_PORT_NUMBER` | MinIO API port number. | `9000` |
| `MINIO_CONSOLE_PORT_NUMBER` | MinIO RMI port number. | `9001` |
| `MINIO_SCHEME` | MinIO web scheme. | `http` |
| `MINIO_SKIP_CLIENT` | Skip MinIO client configuration. | `no` |
| `MINIO_DISTRIBUTED_MODE_ENABLED` | Enable MinIO distributed mode. | `no` |
| `MINIO_DEFAULT_BUCKETS` | MinIO default buckets. | `nil` |
| `MINIO_STARTUP_TIMEOUT` | MinIO startup timeout. | `10` |
| `MINIO_SERVER_URL` | MinIO server external URL. | `$MINIO_SCHEME://localhost:$MINIO_API_PORT_NUMBER` |
| `MINIO_APACHE_CONSOLE_HTTP_PORT_NUMBER` | MinIO Console UI HTTP port, exposed via Apache with basic authentication. | `80` |
| `MINIO_APACHE_CONSOLE_HTTPS_PORT_NUMBER` | MinIO Console UI HTTPS port, exposed via Apache with basic authentication. | `443` |
| `MINIO_APACHE_API_HTTP_PORT_NUMBER` | MinIO API HTTP port, exposed via Apache with basic authentication. | `9000` |
| `MINIO_APACHE_API_HTTPS_PORT_NUMBER` | MinIO API HTTPS port, exposed via Apache with basic authentication. | `9443` |
| `MINIO_FORCE_NEW_KEYS` | Force recreating MinIO keys. | `no` |
| `MINIO_ROOT_USER` | MinIO root user name. | `minio` |
| `MINIO_ROOT_PASSWORD` | Password for MinIO root user. | `miniosecret` |
#### Read-only environment variables
| Name | Description | Value |
|----------------------|---------------------------------------|-------------------------------|
| `MINIO_BASE_DIR` | MinIO installation directory. | `${BITNAMI_ROOT_DIR}/minio` |
| `MINIO_BIN_DIR` | MinIO directory for binaries. | `${MINIO_BASE_DIR}/bin` |
| `MINIO_CERTS_DIR` | MinIO directory for TLS certificates. | `/certs` |
| `MINIO_LOGS_DIR` | MinIO directory for log files. | `${MINIO_BASE_DIR}/log` |
| `MINIO_TMP_DIR` | MinIO directory for log files. | `${MINIO_BASE_DIR}/tmp` |
| `MINIO_SECRETS_DIR` | MinIO directory for credentials. | `${MINIO_BASE_DIR}/secrets` |
| `MINIO_LOG_FILE` | MinIO log file. | `${MINIO_LOGS_DIR}/minio.log` |
| `MINIO_PID_FILE` | MinIO PID file. | `${MINIO_TMP_DIR}/minio.pid` |
| `MINIO_DAEMON_USER` | MinIO system user. | `minio` |
| `MINIO_DAEMON_GROUP` | MinIO system group. | `minio` |
Additionally, MinIO can be configured via environment variables as detailed at [MinIO(R) documentation](https://docs.min.io/docs/minio-server-configuration-guide.html).
A MinIO(R) Client (`mc`) is also shipped on this image that can be used to perform administrative tasks as described at the [MinIO(R) Client documentation](https://docs.min.io/docs/minio-admin-complete-guide.html). In the example below, the client is used to obtain the server info:
```console
docker run --name minio -d bitnami/minio:latest
docker exec minio mc admin info local
```
or using Docker Compose:
```console
curl -sSL https://raw.githubusercontent.com/bitnami/containers/main/bitnami/minio/docker-compose.yml > docker-compose.yml
docker-compose up -d
docker-compose exec minio mc admin info local
```
### Creating default buckets
You can create a series of buckets in the MinIO(R) server during the initialization of the container by setting the environment variable `MINIO_DEFAULT_BUCKETS` as shown below (policy is optional):
```console
docker run --name minio \
--publish 9000:9000 \
--publish 9001:9001 \
--env MINIO_DEFAULT_BUCKETS='my-first-bucket:policy,my-second-bucket' \
bitnami/minio:latest
```
or by modifying the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/minio/docker-compose.yml) file present in this repository:
```yaml
services:
minio:
...
environment:
- MINIO_DEFAULT_BUCKETS=my-first-bucket:policy,my-second-bucket
...
```
### Securing access to MinIO(R) server with TLS
You can secure the access to MinIO(R) server with TLS as detailed at [MinIO(R) documentation](https://docs.min.io/docs/how-to-secure-access-to-minio-server-with-tls.html).
This image expects the variable `MINIO_SCHEME` set to `https` and certificates to be mounted at the `/certs` directory. You can put your key and certificate files on a local directory and mount it in the container as shown below:
```console
docker run --name minio \
--publish 9000:9000 \
--publish 9001:9001 \
--volume /path/to/certs:/certs \
--env MINIO_SCHEME=https
bitnami/minio:latest
```
or by modifying the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/minio/docker-compose.yml) file present in this repository:
```yaml
services:
minio:
...
environment:
...
- MINIO_SCHEME=https
...
volumes:
- /path/to/certs:/certs
...
```
### Setting up MinIO(R) in Distributed Mode
You can configure MinIO(R) in Distributed Mode to setup a highly-available storage system. To do so, the environment variables below **must** be set on each node:
* `MINIO_DISTRIBUTED_MODE_ENABLED`: Set it to 'yes' to enable Distributed Mode.
* `MINIO_DISTRIBUTED_NODES`: List of MinIO(R) nodes hosts. Available separators are ' ', ',' and ';'.
* `MINIO_ROOT_USER`: MinIO(R) server root user. Must be common on every node.
* `MINIO_ROOT_PASSWORD`: MinIO(R) server root password. Must be common on every node.
You can use the Docker Compose below to create an 4-node distributed MinIO(R) setup:
```yaml
version: '2'
services:
minio1:
image: 'bitnami/minio:latest'
environment:
- MINIO_ROOT_USER=minio-root-user
- MINIO_ROOT_PASSWORD=minio-root-password
- MINIO_DISTRIBUTED_MODE_ENABLED=yes
- MINIO_DISTRIBUTED_NODES=minio1,minio2,minio3,minio4
- MINIO_SKIP_CLIENT=yes
minio2:
image: 'bitnami/minio:latest'
environment:
- MINIO_ROOT_USER=minio-root-user
- MINIO_ROOT_PASSWORD=minio-root-password
- MINIO_DISTRIBUTED_MODE_ENABLED=yes
- MINIO_DISTRIBUTED_NODES=minio1,minio2,minio3,minio4
- MINIO_SKIP_CLIENT=yes
minio3:
image: 'bitnami/minio:latest'
environment:
- MINIO_ROOT_USER=minio-root-user
- MINIO_ROOT_PASSWORD=minio-root-password
- MINIO_DISTRIBUTED_MODE_ENABLED=yes
- MINIO_DISTRIBUTED_NODES=minio1,minio2,minio3,minio4
- MINIO_SKIP_CLIENT=yes
minio4:
image: 'bitnami/minio:latest'
environment:
- MINIO_ROOT_USER=minio-root-user
- MINIO_ROOT_PASSWORD=minio-root-password
- MINIO_DISTRIBUTED_MODE_ENABLED=yes
- MINIO_DISTRIBUTED_NODES=minio1,minio2,minio3,minio4
- MINIO_SKIP_CLIENT=yes
```
MinIO(R) also supports ellipsis syntax (`{1..n}`) to list the MinIO(R) node hosts, where `n` is the number of nodes. This syntax is also valid to use multiple drives (`{1..m}`) on each MinIO(R) node, where `n` is the number of drives per node. You can use the Docker Compose below to create an 2-node distributed MinIO(R) setup with 2 drives per node:
```yaml
version: '2'
services:
minio-0:
image: 'bitnami/minio:latest'
volumes:
- 'minio_0_data_0:/bitnami/minio/data-0'
- 'minio_0_data_1:/bitnami/minio/data-1'
environment:
- MINIO_ROOT_USER=minio
- MINIO_ROOT_PASSWORD=miniosecret
- MINIO_DISTRIBUTED_MODE_ENABLED=yes
- MINIO_DISTRIBUTED_NODES=minio-{0...1}/bitnami/minio/data-{0...1}
minio-1:
image: 'bitnami/minio:latest'
volumes:
- 'minio_1_data_0:/bitnami/minio/data-0'
- 'minio_1_data_1:/bitnami/minio/data-1'
environment:
- MINIO_ROOT_USER=minio
- MINIO_ROOT_PASSWORD=miniosecret
- MINIO_DISTRIBUTED_MODE_ENABLED=yes
- MINIO_DISTRIBUTED_NODES=minio-{0...1}/bitnami/minio/data-{0...1}
volumes:
minio_0_data_0:
driver: local
minio_0_data_1:
driver: local
minio_1_data_0:
driver: local
minio_1_data_1:
driver: local
```
Find more information about the Distributed Mode in the [MinIO(R) documentation](https://docs.min.io/docs/distributed-minio-quickstart-guide.html).
### Reconfiguring Keys on container restarts
MinIO(R) configures the access & secret key during the 1st initialization based on the `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD` environment variables, respetively.
When using persistence, MinIO(R) will reuse the data configured during the 1st initialization by default, ignoring whatever values are set on these environment variables. You can force MinIO(R) to reconfigure the keys based on the environment variables by setting the `MINIO_FORCE_NEW_KEYS` environment variable to `yes`:
```console
docker run --name minio \
--publish 9000:9000 \
--publish 9001:9001 \
--env MINIO_FORCE_NEW_KEYS="yes" \
--env MINIO_ROOT_USER="new-minio-root-user" \
--env MINIO_ROOT_PASSWORD="new-minio-root-password" \
--volume /path/to/minio-persistence:/bitnami/minio/data \
bitnami/minio:latest
```
## Logging
The Bitnami MinIO(R) Docker image sends the container logs to the `stdout`. To view the logs:
```console
docker logs minio
```
or using Docker Compose:
```console
docker-compose logs minio
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
### HTTP log trace
To enable HTTP log trace, you can set the environment variable `MINIO_HTTP_TRACE` to redirect the logs to a specific file as detailed at [MinIO(R) documentation](https://docs.min.io/docs/minio-server-configuration-guide.html).
When setting this environment variable to `/opt/bitnami/minio/log/minio.log`, the logs will be sent to the `stdout`.
```console
docker run --name minio \
--publish 9000:9000 \
--publish 9001:9001 \
--env MINIO_HTTP_TRACE=/opt/bitnami/minio/log/minio.log \
bitnami/minio:latest
```
or by modifying the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/minio/docker-compose.yml) file present in this repository:
```yaml
services:
minio:
...
environment:
- MINIO_HTTP_TRACE=/opt/bitnami/minio/log/minio.log
...
```
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of MinIO(R), including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/minio:latest
```
or if you're using Docker Compose, update the value of the image property to
`bitnami/minio:latest`.
#### Step 2: Stop and backup the currently running container
Stop the currently running container using the command
```console
docker stop minio
```
or using Docker Compose:
```console
docker-compose stop minio
```
Next, take a snapshot of the persistent volume `/path/to/minio-persistence` using:
```console
rsync -a /path/to/minio-persistence /path/to/minio-persistence.bkp.$(date +%Y%m%d-%H.%M.%S)
```
#### Step 3: Remove the currently running container
```console
docker rm -v minio
```
or using Docker Compose:
```console
docker-compose rm -v minio
```
#### Step 4: Run the new image
Re-create your container from the new image.
```console
docker run --name minio bitnami/minio:latest
```
or using Docker Compose:
```console
docker-compose up minio
```
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/minio).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this Docker image. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to include the following information in your issue:
* Host OS and version
* Docker version (`docker version`)
* Output of `docker info`
* Version of this container
* The command you used to run the container, and any relevant output you saw (masking any sensitive information)
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

147
bitnami/mlflow/2/debian-12/README.md
View File

@@ -1,147 +0,0 @@
# Bitnami package for MLflow
## What is MLflow?
> MLflow is an open-source platform designed to manage the end-to-end machine learning lifecycle. It allows you to track experiments, package code into reproducible runs, and share and deploy models.
[Overview of MLflow](https://mlflow.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run -it --name mlflow bitnami/mlflow:latest
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use MLflow in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Mlflow Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/mlflow).
```console
docker pull bitnami/mlflow:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/mlflow/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/mlflow:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Entering the REPL
By default, running this image will drop you into the Python REPL, where you can interactively test and try things out with MLflow in Python.
```console
docker run -it --name mlflow bitnami/mlflow
```
## Configuration
### Running your MLflow app
The default work directory for the MLflow image is `/app`. You can mount a folder from your host here that includes your MLflow script, and run it normally using the `python` command.
```console
docker run -it --name mlflow -v /path/to/app:/app bitnami/mlflow \
python script.py
```
### Running a MLflow app with package dependencies
If your MLflow app has a `requirements.txt` defining your app's dependencies, you can install the dependencies before running your app.
```console
docker run -it --name mlflow -v /path/to/app:/app bitnami/mlflow \
sh -c "pip install -r requirements.txt && python script.py"
```
**Further Reading:**
* [mlflow documentation](https://mlflow.org/docs/)
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of MLflow, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/mlflow:latest
```
#### Step 2: Remove the currently running container
```console
docker rm -v mlflow
```
#### Step 3: Run the new image
Re-create your container from the new image.
```console
docker run --name mlflow bitnami/mlflow:latest
```
## Notable Changes
### Starting January 16, 2024
* The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes.
## Contributing
We'd love for you to contribute to this Docker image. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

137
bitnami/nessie-utils/0/debian-12/README.md
View File

@@ -1,137 +0,0 @@
# Bitnami package for Nessie Utils
## What is Nessie Utils?
> Nessie Utils contains the tools nessie-cli, nessie-gc and nessie-admin-server-tool. Nessie is an open-source version control system for data lakes.
[Overview of Nessie Utils](https://projectnessie.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run -it --name nessie-utils bitnami/nessie-utils
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Nessie Utils in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Nessie Utils Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/nessie-utils).
```console
docker pull bitnami/nessie-utils:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/nessie-utils/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/nessie-utils:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of Nessie Utils, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/nessie-utils:latest
```
or if you're using Docker Compose, update the value of the image property to `bitnami/nessie-utils:latest`.
#### Step 2: Remove the currently running container
```console
docker rm -v nessie-utils
```
#### Step 3: Run the new image
Re-create your container from the new image.
```console
docker run --name nessie-utils bitnami/nessie-utils:latest
```
## Configuration
### Running commands
This container contains the nessie-cli, nessie-server-admin-tool and nessie-gc tools. These are the commands for running the different tools:
Running nessie-cli:
```console
docker run --rm --name nessie-utils bitnami/nessie-utils:latest -jar /opt/bitnami/nessie-utils/nessie-cli/nessie-cli.jar
```
Running nessie-gc:
```console
docker run --rm --name nessie-utils bitnami/nessie-utils:latest -jar /opt/bitnami/nessie-utils/nessie-gc/nessie-gc.jar
```
Running nessie-server-admin-tool:
```console
docker run --rm --name nessie-utils bitnami/nessie-utils:latest -jar /opt/bitnami/nessie-utils/nessie-server-admin-tool/quarkus-run.jar
```
Check the [official Nessie Utils documentation](https://projectnessie.org/) for more information about how to use Nessie Utils.
### Configuration variables
This container supports the upstream Nessie Utils environment variables. Check the [official Nessie Utils documentation](https://projectnessie.org//nessie-utils-latest/configuration/) for the possible environment variables.
## Contributing
We'd love for you to contribute to this Docker image. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

113
bitnami/nessie/0/debian-12/README.md
View File

@@ -1,113 +0,0 @@
# Bitnami package for Nessie
## What is Nessie?
> Nessie is an open-source version control system for data lakes, enabling isolated data experimentation before committing changes.
[Overview of Nessie](https://projectnessie.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run -it --name nessie bitnami/nessie
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Nessie in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Nessie Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/nessie).
```console
docker pull bitnami/nessie:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/nessie/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/nessie:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of Nessie, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/nessie:latest
```
or if you're using Docker Compose, update the value of the image property to `bitnami/nessie:latest`.
#### Step 2: Remove the currently running container
```console
docker rm -v nessie
```
#### Step 3: Run the new image
Re-create your container from the new image.
```console
docker run --name nessie bitnami/nessie:latest
```
## Configuration
### Configuration variables
This container supports the upstream Nessie environment variables. Check the [official Nessie documentation](https://projectnessie.org//nessie-latest/configuration/) for the possible environment variables.
## Contributing
We'd love for you to contribute to this Docker image. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

82
bitnami/nginx-ingress-controller/1/debian-12/README.md
View File

@@ -1,82 +0,0 @@
# Bitnami package for NGINX Ingress Controller
## What is NGINX Ingress Controller?
> NGINX Ingress Controller is an Ingress controller that manages external access to HTTP services in a Kubernetes cluster using NGINX.
[Overview of NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
Deploy NGINX Ingress Controller for Kubernetes on your [Kubernetes cluster](https://kubernetes.io/docs/concepts/services-networking/ingress/).
```console
docker run --name nginx-ingress-controller bitnami/nginx-ingress-controller:latest
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use NGINX Ingress Controller in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## How to deploy NGINX Ingress Controller in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami NGINX Ingress Controller Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/nginx-ingress-controller).
Bitnami containers can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Configuration
For further documentation, please check [here](https://github.com/kubernetes/ingress-nginx).
## Notable Changes
### Starting January 16, 2024
* The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes.
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues/new) or submitting a [pull
request](https://github.com/bitnami/containers/pulls/new) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to include the following information in your issue:
* Host OS and version
* Docker version (`docker version`)
* Output of `docker info`
* Version of this container
* The command you used to run the container, and any relevant output you saw (masking any sensitive information)
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

174
bitnami/node-exporter/1/debian-12/README.md
View File

@@ -1,174 +0,0 @@
# Bitnami package for Node Exporter
## What is Node Exporter?
> Prometheus exporter for hardware and OS metrics exposed by UNIX kernels, with pluggable metric collectors.
[Overview of Node Exporter](https://prometheus.io/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run --name node-exporter bitnami/node-exporter:latest
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Node Exporter in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Node Exporter Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/node-exporter).
```console
docker pull bitnami/node-exporter:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/node-exporter/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/node-exporter:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Connecting to other containers
Using [Docker container networking](https://docs.docker.com/engine/userguide/networking/), a different server running inside a container can easily be accessed by your application containers and vice-versa.
Containers attached to the same network can communicate with each other using the container name as the hostname.
### Using the Command Line
#### Step 1: Create a network
```console
docker network create node-exporter-network --driver bridge
```
#### Step 2: Launch the Node Exporter container within your network
Use the `--network <NETWORK>` argument to the `docker run` command to attach the container to the `node-exporter-network` network.
```console
docker run --name node-exporter-node1 --network node-exporter-network bitnami/node-exporter:latest
```
#### Step 3: Run another container
We can launch another container using the same flag (`--network NETWORK`) in the `docker run` command. If you also set a name for your container, you will be able to use it as a hostname in your network.
## Configuration
There is varying support for collectors on each operating system.
Collectors are enabled by providing a `--collector.<name>` flag. Collectors that are enabled by default can be disabled by providing a `--no-collector.<name>` flag.
[Further information](https://prometheus.io/docs/introduction/overview/)
## Logging
The Bitnami Node Exporter Docker image sends the container logs to the `stdout`. To view the logs:
```console
docker logs node-exporter
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of node-exporter, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/node-exporter:latest
```
#### Step 2: Stop and backup the currently running container
Stop the currently running container using the command
```console
docker stop node-exporter
```
Next, take a snapshot of the persistent volume `/path/to/node-exporter-persistence` using:
```console
rsync -a /path/to/node-exporter-persistence /path/to/node-exporter-persistence.bkp.$(date +%Y%m%d-%H.%M.%S)
```
You can use this snapshot to restore the database state should the upgrade fail.
#### Step 3: Remove the currently running container
```console
docker rm -v node-exporter
```
#### Step 4: Run the new image
Re-create your container from the new image, restoring your backup if necessary.
```console
docker run --name node-exporter bitnami/node-exporter:latest
```
## Notable Changes
### Starting January 16, 2024
* The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes.
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

460
bitnami/odoo/16/debian-12/README.md
View File

@@ -1,460 +0,0 @@
# Bitnami package for Odoo
## What is Odoo?
> Odoo is an open source ERP and CRM platform, formerly known as OpenERP, that can connect a wide variety of business operations such as sales, supply chain, finance, and project management.
[Overview of Odoo](https://www.odoo.com/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run --name odoo bitnami/odoo:latest
```
**Warning**: This quick setup is only intended for development environments. You are encouraged to change the insecure default credentials and check out the available configuration options in the [Environment Variables](#environment-variables) section for a more secure d
eployment.
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Odoo in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## How to deploy Odoo in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the
[Bitnami Odoo Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/odoo).
Bitnami containers can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Odoo Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/odoo).
```console
docker pull bitnami/odoo:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/odoo/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/odoo:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## How to use this image
Odoo requires access to a PostgreSQL database to store information. We'll use the [Bitnami Docker Image for PostgreSQL](https://github.com/bitnami/containers/tree/main/bitnami/postgresql) for the database requirements.
### Using the Docker Command Line
#### Step 1: Create a network
```console
docker network create odoo-network
```
#### Step 2: Create a volume for PostgreSQL persistence and create a PostgreSQL container
```console
$ docker volume create --name postgresql_data
docker run -d --name postgresql \
--env ALLOW_EMPTY_PASSWORD=yes \
--env POSTGRESQL_PASSWORD=bitnami \
--network odoo-network \
--volume postgresql_data:/bitnami/postgresql \
bitnami/postgresql:latest
```
#### Step 3: Create volumes for Odoo persistence and launch the container
```console
$ docker volume create --name odoo_data
docker run -d --name odoo \
-p 80:8069 \
--env ALLOW_EMPTY_PASSWORD=yes \
--env ODOO_DATABASE_ADMIN_PASSWORD=bitnami \
--network odoo-network \
--volume odoo_data:/bitnami/odoo \
bitnami/odoo:latest
```
Access your application at `http://your-ip/`
### Run the application using Docker Compose
```console
curl -sSL https://raw.githubusercontent.com/bitnami/containers/main/bitnami/odoo/docker-compose.yml > docker-compose.yml
docker-compose up -d
```
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/odoo).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Persisting your application
If you remove the container all your data will be lost, and the next time you run the image the database will be reinitialized. To avoid this loss of data, you should mount a volume that will persist even after the container is removed.
For persistence you should mount a directory at the `/bitnami/odoo` path. If the mounted directory is empty, it will be initialized on the first run. Additionally you should [mount a volume for persistence of the PostgreSQL data](https://github.com/bitnami/containers/tree/main/bitnami/postgresql#persisting-your-database).
The above examples define the Docker volumes named `postgresql_data` and `odoo_data`. The Odoo application state will persist as long as volumes are not removed.
To avoid inadvertent removal of volumes, you can [mount host directories as data volumes](https://docs.docker.com/engine/tutorials/dockervolumes/). Alternatively you can make use of volume plugins to host the volume data.
### Mount host directories as data volumes with Docker Compose
This requires a minor change to the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/odoo/docker-compose.yml) file present in this repository:
```diff
postgresql:
...
volumes:
- - 'postgresql_data:/bitnami/postgresql'
+ - /path/to/postgresql-persistence:/bitnami/postgresql
...
odoo:
...
volumes:
- - 'odoo_data:/bitnami/odoo'
+ - /path/to/odoo-persistence:/bitnami/odoo
...
-volumes:
- postgresql_data:
- driver: local
- odoo_data:
- driver: local
```
> NOTE: As this is a non-root container, the mounted files and directories must have the proper permissions for the UID `1001`.
### Mount host directories as data volumes using the Docker command line
#### Step 1: Create a network (if it does not exist)
```console
docker network create odoo-network
```
#### Step 2. Create a PostgreSQL container with host volume
```console
docker run -d --name postgresql \
--env ALLOW_EMPTY_PASSWORD=yes \
--env POSTGRESQL_PASSWORD=bitnami \
--network odoo-network \
--volume /path/to/postgresql-persistence:/bitnami/postgresql \
bitnami/postgresql:latest
```
#### Step 3. Create the Odoo container with host volumes
```console
docker run -d --name odoo \
-p 80:8069 \
--env ALLOW_EMPTY_PASSWORD=yes \
--env ODOO_DATABASE_ADMIN_PASSWORD=bitnami \
--network odoo-network \
--volume /path/to/odoo-persistence:/bitnami/odoo \
bitnami/odoo:latest
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|--------------------------------|----------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|
| `ODOO_DATA_TO_PERSIST` | Files to persist relative to the Odoo installation directory. To provide multiple values, separate them with a whitespace. | `${ODOO_ADDONS_DIR} ${ODOO_CONF_DIR} ${ODOO_DATA_DIR}` |
| `ODOO_PORT_NUMBER` | Port number in which Odoo will run. | `8069` |
| `ODOO_LONGPOLLING_PORT_NUMBER` | Port number in which the Odoo Longpolling service will run. | `8072` |
| `ODOO_SKIP_BOOTSTRAP` | Whether to perform initial bootstrapping for the application. | `no` |
| `ODOO_SKIP_MODULES_UPDATE` | Whether to perform initial update of the plugins installed. | `no` |
| `ODOO_LOAD_DEMO_DATA` | Whether to load demo data. | `no` |
| `ODOO_LIST_DB` | Whether the database selector is available. | `no` |
| `ODOO_EMAIL` | Odoo user e-mail address. | `user@example.com` |
| `ODOO_PASSWORD` | Odoo user password. | `bitnami` |
| `ODOO_SMTP_HOST` | Odoo SMTP server host. | `nil` |
| `ODOO_SMTP_PORT_NUMBER` | Odoo SMTP server port number. | `nil` |
| `ODOO_SMTP_USER` | Odoo SMTP server user. | `nil` |
| `ODOO_SMTP_PASSWORD` | Odoo SMTP server user password. | `nil` |
| `ODOO_SMTP_PROTOCOL` | Odoo SMTP server protocol to use. | `nil` |
| `ODOO_DATABASE_HOST` | Database server host. | `$ODOO_DEFAULT_DATABASE_HOST` |
| `ODOO_DATABASE_PORT_NUMBER` | Database server port. | `5432` |
| `ODOO_DATABASE_NAME` | Database name. | `bitnami_odoo` |
| `ODOO_DATABASE_USER` | Database user name. | `bn_odoo` |
| `ODOO_DATABASE_PASSWORD` | Database user password. | `nil` |
| `ODOO_DATABASE_FILTER` | Database filter | `nil` |
#### Read-only environment variables
| Name | Description | Value |
|------------------------------|-------------------------------------------------|-----------------------------------------------|
| `ODOO_BASE_DIR` | Odoo installation directory. | `${BITNAMI_ROOT_DIR}/odoo` |
| `ODOO_BIN_DIR` | Odoo directory for binary executables. | `${ODOO_BASE_DIR}/bin` |
| `ODOO_CONF_DIR` | Odoo directory for configuration files. | `${ODOO_BASE_DIR}/conf` |
| `ODOO_CONF_FILE` | Configuration file for Odoo. | `${ODOO_CONF_DIR}/odoo.conf` |
| `ODOO_DATA_DIR` | Odoo directory for data files. | `${ODOO_BASE_DIR}/data` |
| `ODOO_ADDONS_DIR` | Odoo directory for addons. | `${ODOO_ADDONS_DIR:-${ODOO_BASE_DIR}/addons}` |
| `ODOO_TMP_DIR` | Odoo directory for temporary files. | `${ODOO_BASE_DIR}/tmp` |
| `ODOO_PID_FILE` | PID file for Odoo. | `${ODOO_TMP_DIR}/odoo.pid` |
| `ODOO_LOGS_DIR` | Odoo directory for log files. | `${ODOO_BASE_DIR}/log` |
| `ODOO_LOG_FILE` | Log file for Odoo. | `${ODOO_LOGS_DIR}/odoo-server.log` |
| `ODOO_VOLUME_DIR` | Odoo directory for mounted configuration files. | `${BITNAMI_VOLUME_DIR}/odoo` |
| `ODOO_DAEMON_USER` | Odoo system user. | `odoo` |
| `ODOO_DAEMON_GROUP` | Odoo system group. | `odoo` |
| `ODOO_DEFAULT_DATABASE_HOST` | Default database server host. | `postgresql` |
When you start the Odoo image, you can adjust the configuration of the instance by passing one or more environment variables either on the docker-compose file or on the `docker run` command line. If you want to add a new environment variable:
* For docker-compose add the variable name and value under the application section in the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/odoo/docker-compose.yml) file present in this repository:
```yaml
odoo:
...
environment:
- ODOO_PASSWORD=my_password
...
```
* For manual execution add a `--env` option with each variable and value:
```console
$ docker run -d --name odoo -p 80:8069 \
--env ODOO_PASSWORD=my_password \
--network odoo-tier \
--volume /path/to/odoo-persistence:/bitnami \
bitnami/odoo:latest
```
### Examples
#### SMTP configuration using a Gmail account
This would be an example of SMTP configuration using a Gmail account:
* Modify the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/odoo/docker-compose.yml) file present in this repository:
```yaml
odoo:
...
environment:
- ALLOW_EMPTY_PASSWORD=yes
- ODOO_SMTP_HOST=smtp.gmail.com
- ODOO_SMTP_PORT_NUMBER=587
- ODOO_SMTP_USER=your_email@gmail.com
- ODOO_SMTP_PASSWORD=your_password
...
```
* For manual execution:
```console
$ docker run -d --name odoo -p 80:8069 \
--env ODOO_SMTP_HOST=smtp.gmail.com \
--env ODOO_SMTP_PORT_NUMBER=587 \
--env ODOO_SMTP_USER=your_email@gmail.com \
--env ODOO_SMTP_PASSWORD=your_password \
--network odoo-tier \
--volume /path/to/odoo-persistence:/bitnami \
bitnami/odoo:latest
```
#### Connect Odoo container to an existing database
The Bitnami Odoo container supports connecting the Odoo application to an external database. This would be an example of using an external database for Odoo.
* Modify the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/odoo/docker-compose.yml) file present in this repository:
```diff
odoo:
...
environment:
- - ODOO_DATABASE_HOST=mariadb
+ - ODOO_DATABASE_HOST=mariadb_host
- ODOO_DATABASE_PORT_NUMBER=3306
- - ALLOW_EMPTY_PASSWORD=yes
+ - ODOO_DATABASE_ADMIN_PASSWORD=odoo_password
...
```
* For manual execution:
```console
$ docker run -d --name odoo\
-p 80:8069 \
--network odoo-network \
--env ODOO_DATABASE_HOST=mariadb_host \
--env ODOO_DATABASE_PORT_NUMBER=3306 \
--env ODOO_DATABASE_ADMIN_PASSWORD=odoo_password \
--volume odoo_data:/bitnami/odoo \
bitnami/odoo:latest
```
In case the database already contains data from a previous Odoo installation, you need to set the variable `ODOO_SKIP_BOOTSTRAP` to `yes`. Otherwise, the container would execute the installation wizard and could modify the existing data in the database. Note that, when setting `ODOO_SKIP_BOOTSTRAP` to `yes`, values for environment variables such as `ODOO_EMAIL` or `ODOO_PASSWORD` will be ignored.
## Logging
The Bitnami Odoo Docker image sends the container logs to `stdout`. To view the logs:
```console
docker logs odoo
```
Or using Docker Compose:
```console
docker-compose logs odoo
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Maintenance
### Backing up your container
To backup your data, configuration and logs, follow these simple steps:
#### Step 1: Stop the currently running container
```console
docker stop odoo
```
Or using Docker Compose:
```console
docker-compose stop odoo
```
#### Step 2: Run the backup command
We need to mount two volumes in a container we will use to create the backup: a directory on your host to store the backup in, and the volumes from the container we just stopped so we can access the data.
```console
docker run --rm -v /path/to/odoo-backups:/backups --volumes-from odoo busybox \
cp -a /bitnami/odoo /backups/latest
```
### Restoring a backup
Restoring a backup is as simple as mounting the backup as volumes in the containers.
For the PostgreSQL database container:
```diff
$ docker run -d --name postgresql \
...
- --volume /path/to/postgresql-persistence:/bitnami/postgresql \
+ --volume /path/to/postgresql-backups/latest:/bitnami/postgresql \
bitnami/postgresql:latest
```
For the Odoo container:
```diff
$ docker run -d --name odoo \
...
- --volume /path/to/odoo-persistence:/bitnami/odoo \
+ --volume /path/to/odoo-backups/latest:/bitnami/odoo \
bitnami/odoo:latest
```
### Upgrade this image
Bitnami provides up-to-date versions of PostgreSQL and Odoo, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container. We will cover here the upgrade of the Odoo container. For the PostgreSQL upgrade see: <https://github.com/bitnami/containers/tree/main/bitnami/odoo#user-content-upgrade-this-image>
The `bitnami/odoo:latest` tag always points to the most recent release. To get the most recent release you can simple repull the `latest` tag from the Docker Hub with `docker pull bitnami/odoo:latest`. However it is recommended to use [tagged versions](https://hub.docker.com/r/bitnami/odoo/tags/).
#### Step 1: Get the updated image
```console
docker pull bitnami/odoo:latest
```
#### Step 2: Stop the running container
Stop the currently running container using the command
```console
docker-compose stop odoo
```
#### Step 3: Take a snapshot of the application state
Follow the steps in [Backing up your container](#backing-up-your-container) to take a snapshot of the current application state.
#### Step 4: Remove the currently running container
Remove the currently running container by executing the following command:
```console
docker-compose rm -v odoo
```
#### Step 5: Run the new image
Update the image tag in `docker-compose.yml` and re-create your container with the new image:
```console
docker-compose up -d
```
## Notable Changes
### 12.0.20210615-debian-10-r20, 13.0.20210610-debian-10-r24 and 14.0.20210610-debian-10-r22
* The size of the container image has been decreased.
* The configuration logic is now based on Bash scripts in the *rootfs/* folder.
* It is now possible to use an already populated Odoo database from another installation. In order to do this, use the environment variable `ODOO_SKIP_BOOTSTRAP`, which forces the container not to run the initial Odoo setup wizard.
* Removed port 8071 from list of exposed ports. This port was used by the Odoo XMLRPCS service, but was removed in Odoo 10.
* Added port 8072 to the list of exposed ports. This port is used by the [Odoo Longpolling service](https://www.odoo.com/documentation/14.0/administration/deployment/deploy.html#livechat).
* The `WITHOUT_DEMO` environment variable was deprecated in favor of the boolean `ODOO_LOAD_DEMO_DATA` environment variable.
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

329
bitnami/ruby/3.3/debian-12/README.md
View File

@@ -1,329 +0,0 @@
# Bitnami package for Ruby
## What is Ruby?
> Ruby on Rails is a full-stack development environment optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.
[Overview of Ruby](http://www.ruby-lang.org)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run -it --name ruby bitnami/ruby:latest
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Ruby in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
### Deprecation Note (2022-01-21)
The `prod` tags has been removed; from now on just the regular container images will be released.
### Deprecation Note (2020-08-18)
The formatting convention for `prod` tags has been changed:
* `BRANCH-debian-10-prod` is now tagged as `BRANCH-prod-debian-10`
* `VERSION-debian-10-rX-prod` is now tagged as `VERSION-prod-debian-10-rX`
* `latest-prod` is now deprecated
## Get this image
The recommended way to get the Bitnami Ruby Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/ruby).
```console
docker pull bitnami/ruby:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/ruby/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/ruby:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Entering the REPL
By default, running this image will drop you into the Ruby REPL (`irb`), where you can interactively test and try things out in Ruby.
```console
docker run -it --name ruby bitnami/ruby:latest
```
**Further Reading:**
* [Ruby IRB Documentation](http://ruby-doc.org/stdlib-2.4.0/libdoc/irb/rdoc/IRB.html)
## Configuration
### Running your Ruby script
The default work directory for the Ruby image is `/app`. You can mount a folder from your host here that includes your Ruby script, and run it normally using the `ruby` command.
```console
docker run -it --name ruby -v /path/to/app:/app bitnami/ruby:latest \
ruby script.rb
```
### Running a Ruby app with gems
If your Ruby app has a `Gemfile` defining your app's dependencies and start script, you can install the dependencies before running your app.
```console
docker run -it --name ruby -v /path/to/app:/app bitnami/ruby:latest \
sh -c "bundle install && ruby script.rb"
```
or by modifying the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/ruby/docker-compose.yml) file present in this repository:
```yaml
ruby:
...
command: "sh -c 'bundle install && ruby script.rb'"
volumes:
- .:/app
...
```
**Further Reading:**
* [rubygems.org](https://rubygems.org/)
* [bundler.io](http://bundler.io/)
### Accessing a Ruby app running a web server
This image exposes port `3000` in the container, so you should ensure that your web server is binding to port `3000`, as well as listening on `0.0.0.0` to accept remote connections from your host.
Below is an example of a [Sinatra](http://www.sinatrarb.com/) app listening to remote connections on port `3000`:
```ruby
require 'sinatra'
set :bind, '0.0.0.0'
set :port, 3000
get '/hi' do
"Hello World!"
end
```
To access your web server from your host machine you can ask Docker to map a random port on your host to port `3000` inside the container.
```console
docker run -it --name ruby -P bitnami/ruby:latest
```
Run `docker port` to determine the random port Docker assigned.
```console
$ docker port ruby
3000/tcp -> 0.0.0.0:32769
```
You can also manually specify the port you want forwarded from your host to the container.
```console
docker run -it --name ruby -p 8080:3000 bitnami/ruby:latest
```
Access your web server in the browser by navigating to `http://localhost:8080`.
## Connecting to other containers
If you want to connect to your Ruby web server inside another container, you can use docker networking to create a network and attach all the containers to that network.
### Serving your Ruby app through an nginx frontend
We may want to make our Ruby web server only accessible via an nginx web server. Doing so will allow us to setup more complex configuration, serve static assets using nginx, load balance to different Ruby instances, etc.
#### Step 1: Create a network
```console
docker network create app-tier --driver bridge
```
or using Docker Compose:
```yaml
version: '2'
networks:
app-tier:
driver: bridge
```
#### Step 2: Create a virtual host
Let's create an nginx virtual host to reverse proxy to our Ruby container.
```nginx
server {
listen 0.0.0.0:80;
server_name yourapp.com;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header HOST $http_host;
proxy_set_header X-NginX-Proxy true;
# proxy_pass http://[your_ruby_container_link_alias]:3000;
proxy_pass http://myapp:3000;
proxy_redirect off;
}
}
```
Notice we've substituted the link alias name `myapp`, we will use the same name when creating the container.
Copy the virtual host above, saving the file somewhere on your host. We will mount it as a volume in our nginx container.
#### Step 3: Run the Ruby image with a specific name
```console
docker run -it --name myapp \
--network app-tier \
-v /path/to/app:/app \
bitnami/ruby:latest ruby script.rb
```
or using Docker Compose:
```yaml
version: '2'
myapp:
image: bitnami/ruby:latest
command: ruby script.rb
networks:
- app-tier
volumes:
- .:/app
```
#### Step 4: Run the nginx image
```console
docker run -it \
-v /path/to/vhost.conf:/bitnami/nginx/conf/vhosts/yourapp.conf \
--network app-tier \
bitnami/nginx:latest
```
or using Docker Compose:
```yaml
version: '2'
nginx:
image: bitnami/nginx:latest
networks:
- app-tier
volumes:
- /path/to/vhost.conf:/bitnami/nginx/conf/vhosts/yourapp.conf
```
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of Ruby, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/ruby:latest
```
or if you're using Docker Compose, update the value of the image property to `bitnami/ruby:latest`.
#### Step 2: Remove the currently running container
```console
docker rm -v ruby
```
or using Docker Compose:
```console
docker-compose rm -v ruby
```
#### Step 3: Run the new image
Re-create your container from the new image.
```console
docker run --name ruby bitnami/ruby:latest
```
or using Docker Compose:
```console
docker-compose up ruby
```
## Notable Changes
### 2.3.1-r0 (2016-05-11)
* Commands are now executed as the `root` user. Use the `--user` argument to switch to another user or change to the required user using `sudo` to launch applications. Alternatively, as of Docker 1.10 User Namespaces are supported by the docker daemon. Refer to the [daemon user namespace options](https://docs.docker.com/engine/security/userns-remap/) for more details.
### 2.2.3-0-r02 (2015-09-30)
* `/app` directory no longer exported as a volume. This caused problems when building on top of the image, since changes in the volume were not persisted between RUN commands. To keep the previous behavior (so that you can mount the volume in another container), create the container with the `-v /app` option.
### 2.2.3-0-r01 (2015-08-26)
* Permissions fixed so `bitnami` user can install gems without needing `sudo`.
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes.
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

478
bitnami/sonarqube/10/debian-12/README.md
View File

@@ -1,478 +0,0 @@
# Bitnami package for SonarQube&trade;
## What is SonarQube&trade;?
> SonarQube&trade; is an open source quality management platform that analyzes and measures code's technical quality. It enables developers to detect code issues, vulnerabilities, and bugs in early stages.
[Overview of SonarQube&trade;](http://www.sonarqube.org)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement. SonarQube is a registered trademark of SonarSource SA.
## TL;DR
```console
docker run --name sonarqube bitnami/sonarqube:latest
```
**Warning**: This quick setup is only intended for development environments. You are encouraged to change the insecure default credentials and check out the available configuration options in the [Environment Variables](#environment-variables) section for a more secure deployment.
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use SonarQube&trade; in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami SonarQube&trade; Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/sonarqube).
```console
docker pull bitnami/sonarqube:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/sonarqube/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/sonarqube:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## How to use this image
SonarQube&trade; requires access to a PostgreSQL database to store information. We'll use the [Bitnami Docker Image for PostgreSQL](https://github.com/bitnami/containers/tree/main/bitnami/postgresql) for the database requirements.
### Using the Docker Command Line
#### Step 1: Create a network
```console
docker network create sonarqube-network
```
#### Step 2: Create a volume for PostgreSQL persistence and create a PostgreSQL container
```console
$ docker volume create --name postgresql_data
docker run -d --name postgresql \
--env ALLOW_EMPTY_PASSWORD=yes \
--env POSTGRESQL_USERNAME=bn_sonarqube \
--env POSTGRESQL_PASSWORD=bitnami \
--env POSTGRESQL_DATABASE=bitnami_sonarqube \
--network sonarqube-network \
--volume postgresql_data:/bitnami/postgresql \
bitnami/postgresql:latest
```
#### Step 3: Create volumes for SonarQube&trade; persistence and launch the container
```console
$ docker volume create --name sonarqube_data
docker run -d --name sonarqube \
-p 8080:8080 -p 8443:8443 \
--env ALLOW_EMPTY_PASSWORD=yes \
--env SONARQUBE_DATABASE_USER=bn_sonarqube \
--env SONARQUBE_DATABASE_PASSWORD=bitnami \
--env SONARQUBE_DATABASE_NAME=bitnami_sonarqube \
--network sonarqube-network \
--volume sonarqube_data:/bitnami/sonarqube \
bitnami/sonarqube:latest
```
Access your application at `http://your-ip/`
### Run the application using Docker Compose
```console
curl -sSL https://raw.githubusercontent.com/bitnami/containers/main/bitnami/sonarqube/docker-compose.yml > docker-compose.yml
docker-compose up -d
```
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/apache).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Persisting your application
If you remove the container all your data will be lost, and the next time you run the image the database will be reinitialized. To avoid this loss of data, you should mount a volume that will persist even after the container is removed.
For persistence you should mount a directory at the `/bitnami/sonarqube` path. If the mounted directory is empty, it will be initialized on the first run. Additionally you should [mount a volume for persistence of the PostgreSQL data](https://github.com/bitnami/containers/tree/main/bitnami/postgresql#persisting-your-database).
The above examples define the Docker volumes named `postgresql_data` and `sonarqube_data`. The SonarQube&trade; application state will persist as long as volumes are not removed.
To avoid inadvertent removal of volumes, you can [mount host directories as data volumes](https://docs.docker.com/engine/tutorials/dockervolumes/). Alternatively you can make use of volume plugins to host the volume data.
### Mount host directories as data volumes with Docker Compose
This requires a minor change to the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/sonarqube/docker-compose.yml) file present in this repository:
```diff
postgresql:
...
volumes:
- - 'postgresql_data:/bitnami/postgresql'
+ - /path/to/postgresql-persistence:/bitnami/postgresql
...
sonarqube:
...
volumes:
- - 'sonarqube_data:/bitnami/sonarqube'
+ - /path/to/sonarqube-persistence:/bitnami/sonarqube
...
-volumes:
- postgresql_data:
- driver: local
- sonarqube_data:
- driver: local
```
> NOTE: As this is a non-root container, the mounted files and directories must have the proper permissions for the UID `1001`.
### Mount host directories as data volumes using the Docker command line
#### Step 1: Create a network (if it does not exist)
```console
docker network create sonarqube-network
```
#### Step 2. Create a PostgreSQL container with host volume
```console
docker run -d --name postgresql \
--env ALLOW_EMPTY_PASSWORD=yes \
--env POSTGRESQL_USERNAME=bn_sonarqube \
--env POSTGRESQL_PASSWORD=bitnami \
--env POSTGRESQL_DATABASE=bitnami_sonarqube \
--network sonarqube-network \
--volume /path/to/postgresql-persistence:/bitnami/postgresql \
bitnami/postgresql:latest
```
#### Step 3. Create the SonarQube&trade; container with host volumes
```console
docker run -d --name sonarqube \
-p 8080:8080 -p 8443:8443 \
--env ALLOW_EMPTY_PASSWORD=yes \
--env SONARQUBE_DATABASE_USER=bn_sonarqube \
--env SONARQUBE_DATABASE_PASSWORD=bitnami \
--env SONARQUBE_DATABASE_NAME=bitnami_sonarqube \
--network sonarqube-network \
--volume /path/to/sonarqube-persistence:/bitnami/sonarqube \
bitnami/sonarqube:latest
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|-----------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------|
| `SONARQUBE_MOUNTED_PROVISIONING_DIR` | Directory for SonarQube initial provisioning. | `/bitnami/sonarqube-provisioning` |
| `SONARQUBE_DATA_TO_PERSIST` | Files to persist relative to the SonarQube installation directory. To provide multiple values, separate them with a whitespace. | `${SONARQUBE_DATA_DIR} ${SONARQUBE_EXTENSIONS_DIR}` |
| `SONARQUBE_PORT_NUMBER` | SonarQube Web application port number. | `9000` |
| `SONARQUBE_ELASTICSEARCH_PORT_NUMBER` | SonarQube Elasticsearch application port number. | `9001` |
| `SONARQUBE_START_TIMEOUT` | Timeout for the application to start in seconds. | `300` |
| `SONARQUBE_SKIP_BOOTSTRAP` | Whether to perform initial bootstrapping for the application. | `no` |
| `SONARQUBE_WEB_CONTEXT` | SonarQube prefix used to access to the application. | `/` |
| `SONARQUBE_MAX_HEAP_SIZE` | Maximum heap size for SonarQube services (CE, Search and Web). | `nil` |
| `SONARQUBE_MIN_HEAP_SIZE` | Minimum heap size for SonarQube services (CE, Search and Web). | `nil` |
| `SONARQUBE_CE_JAVA_ADD_OPTS` | Additional Java options for Compute Engine. | `nil` |
| `SONARQUBE_ELASTICSEARCH_JAVA_ADD_OPTS` | Additional Java options for Elasticsearch. | `nil` |
| `SONARQUBE_WEB_JAVA_ADD_OPTS` | Additional Java options for Web. | `nil` |
| `SONARQUBE_EXTRA_PROPERTIES` | Comma separated list of properties to be set in the sonar.properties file, e.g. `my.sonar.property1=property_value,my.sonar.property2=property_value`. | `nil` |
| `SONARQUBE_USERNAME` | SonarQube user name. | `admin` |
| `SONARQUBE_PASSWORD` | SonarQube user password. | `bitnami` |
| `SONARQUBE_EMAIL` | SonarQube user e-mail address. | `user@example.com` |
| `SONARQUBE_SMTP_HOST` | SonarQube SMTP server host. | `nil` |
| `SONARQUBE_SMTP_PORT_NUMBER` | SonarQube SMTP server port number. | `nil` |
| `SONARQUBE_SMTP_USER` | SonarQube SMTP server user. | `nil` |
| `SONARQUBE_SMTP_PASSWORD` | SonarQube SMTP server user password. | `nil` |
| `SONARQUBE_SMTP_PROTOCOL` | SonarQube SMTP server protocol to use. | `nil` |
| `SONARQUBE_DATABASE_HOST` | Database server host. | `$SONARQUBE_DEFAULT_DATABASE_HOST` |
| `SONARQUBE_DATABASE_PORT_NUMBER` | Database server port. | `5432` |
| `SONARQUBE_DATABASE_NAME` | Database name. | `bitnami_sonarqube` |
| `SONARQUBE_DATABASE_USER` | Database user name. | `bn_sonarqube` |
| `SONARQUBE_DATABASE_PASSWORD` | Database user password. | `nil` |
#### Read-only environment variables
| Name | Description | Value |
|-----------------------------------|------------------------------------------------------|--------------------------------------------|
| `SONARQUBE_BASE_DIR` | SonarQube installation directory. | `${BITNAMI_ROOT_DIR}/sonarqube` |
| `SONARQUBE_DATA_DIR` | Directory for SonarQube data files. | `${SONARQUBE_BASE_DIR}/data` |
| `SONARQUBE_EXTENSIONS_DIR` | Directory for SonarQube extensions. | `${SONARQUBE_BASE_DIR}/extensions` |
| `SONARQUBE_CONF_DIR` | Directory for SonarQube configuration files. | `${SONARQUBE_BASE_DIR}/conf` |
| `SONARQUBE_CONF_FILE` | Configuration file for SonarQube. | `${SONARQUBE_CONF_DIR}/sonar.properties` |
| `SONARQUBE_LOGS_DIR` | Directory for SonarQube log files. | `${SONARQUBE_BASE_DIR}/logs` |
| `SONARQUBE_LOG_FILE` | SonarQube log file. | `${SONARQUBE_LOGS_DIR}/sonar.log` |
| `SONARQUBE_TMP_DIR` | Directory for SonarQube temporary files. | `${SONARQUBE_BASE_DIR}/temp` |
| `SONARQUBE_PID_FILE` | SonarQube PID file. | `${SONARQUBE_BASE_DIR}/pids/SonarQube.pid` |
| `SONARQUBE_BIN_DIR` | SonarQube directory for binary executables. | `${SONARQUBE_BASE_DIR}/bin/linux-x86-64` |
| `SONARQUBE_VOLUME_DIR` | SonarQube directory for mounted configuration files. | `${BITNAMI_VOLUME_DIR}/sonarqube` |
| `SONARQUBE_DAEMON_USER` | SonarQube system user. | `sonarqube` |
| `SONARQUBE_DAEMON_USER_ID` | SonarQube system user ID. | `1001` |
| `SONARQUBE_DAEMON_GROUP` | SonarQube system group. | `sonarqube` |
| `SONARQUBE_DAEMON_GROUP_ID` | SonarQube system group. | `1001` |
| `SONARQUBE_DEFAULT_DATABASE_HOST` | Default database server host. | `postgresql` |
When you start the SonarQube&trade; image, you can adjust the configuration of the instance by passing one or more environment variables either on the docker-compose file or on the `docker run` command line. If you want to add a new environment variable:
* For docker-compose add the variable name and value under the application section in the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/sonarqube/docker-compose.yml) file present in this repository:
```yaml
sonarqube:
...
environment:
- SONARQUBE_PASSWORD=my_password
...
```
* For manual execution add a `--env` option with each variable and value:
```console
$ docker run -d --name sonarqube -p 80:8080 -p 443:8443 \
--env SONARQUBE_PASSWORD=my_password \
--network sonarqube-tier \
--volume /path/to/sonarqube-persistence:/bitnami \
bitnami/sonarqube:latest
```
### Examples
#### SMTP configuration using a Gmail account
This would be an example of SMTP configuration using a Gmail account:
* Modify the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/sonarqube/docker-compose.yml) file present in this repository:
```yaml
sonarqube:
...
environment:
- SONARQUBE_DATABASE_USER=bn_sonarqube
- SONARQUBE_DATABASE_NAME=bitnami_sonarqube
- ALLOW_EMPTY_PASSWORD=yes
- SONARQUBE_SMTP_HOST=smtp.gmail.com
- SONARQUBE_SMTP_PORT_NUMBER=587
- SONARQUBE_SMTP_USER=your_email@gmail.com
- SONARQUBE_SMTP_PASSWORD=your_password
...
```
* For manual execution:
```console
$ docker run -d --name sonarqube -p 80:8080 -p 443:8443 \
--env SONARQUBE_DATABASE_USER=bn_sonarqube \
--env SONARQUBE_DATABASE_NAME=bitnami_sonarqube \
--env SONARQUBE_SMTP_HOST=smtp.gmail.com \
--env SONARQUBE_SMTP_PORT_NUMBER=587 \
--env SONARQUBE_SMTP_USER=your_email@gmail.com \
--env SONARQUBE_SMTP_PASSWORD=your_password \
--network sonarqube-tier \
--volume /path/to/sonarqube-persistence:/bitnami \
bitnami/sonarqube:latest
```
#### Connect SonarQube&trade; container to an existing database
The Bitnami SonarQube&trade; container supports connecting the SonarQube&trade; application to an external database. This would be an example of using an external database for SonarQube&trade;.
* Modify the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/sonarqube/docker-compose.yml) file present in this repository:
```diff
sonarqube:
...
environment:
- - SONARQUBE_DATABASE_HOST=mariadb
+ - SONARQUBE_DATABASE_HOST=mariadb_host
- SONARQUBE_DATABASE_PORT_NUMBER=3306
- SONARQUBE_DATABASE_NAME=sonarqube_db
- SONARQUBE_DATABASE_USER=sonarqube_user
- - ALLOW_EMPTY_PASSWORD=yes
+ - SONARQUBE_DATABASE_PASSWORD=sonarqube_password
...
```
* For manual execution:
```console
$ docker run -d --name sonarqube\
-p 8080:8080 -p 8443:8443 \
--network sonarqube-network \
--env SONARQUBE_DATABASE_HOST=mariadb_host \
--env SONARQUBE_DATABASE_PORT_NUMBER=3306 \
--env SONARQUBE_DATABASE_NAME=sonarqube_db \
--env SONARQUBE_DATABASE_USER=sonarqube_user \
--env SONARQUBE_DATABASE_PASSWORD=sonarqube_password \
--volume sonarqube_data:/bitnami/sonarqube \
bitnami/sonarqube:latest
```
In case the database already contains data from a previous SonarQube&trade; installation, you need to set the variable `SONARQUBE_SKIP_BOOTSTRAP` to `yes`. Otherwise, the container would execute the installation wizard and could modify the existing data in the database. Note that, when setting `SONARQUBE_SKIP_BOOTSTRAP` to `yes`, values for environment variables such as `SONARQUBE_USERNAME`, `SONARQUBE_PASSWORD` or `SONARQUBE_EMAIL` will be ignored.
## Logging
The Bitnami SonarQube&trade; Docker image sends the container logs to `stdout`. To view the logs:
```console
docker logs sonarqube
```
Or using Docker Compose:
```console
docker-compose logs sonarqube
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Maintenance
### Backing up your container
To backup your data, configuration and logs, follow these simple steps:
#### Step 1: Stop the currently running container
```console
docker stop sonarqube
```
Or using Docker Compose:
```console
docker-compose stop sonarqube
```
#### Step 2: Run the backup command
We need to mount two volumes in a container we will use to create the backup: a directory on your host to store the backup in, and the volumes from the container we just stopped so we can access the data.
```console
docker run --rm -v /path/to/sonarqube-backups:/backups --volumes-from sonarqube busybox \
cp -a /bitnami/sonarqube /backups/latest
```
### Restoring a backup
Restoring a backup is as simple as mounting the backup as volumes in the containers.
For the PostgreSQL database container:
```diff
$ docker run -d --name postgresql \
...
- --volume /path/to/postgresql-persistence:/bitnami/postgresql \
+ --volume /path/to/postgresql-backups/latest:/bitnami/postgresql \
bitnami/postgresql:latest
```
For the SonarQube&trade; container:
```diff
$ docker run -d --name sonarqube \
...
- --volume /path/to/sonarqube-persistence:/bitnami/sonarqube \
+ --volume /path/to/sonarqube-backups/latest:/bitnami/sonarqube \
bitnami/sonarqube:latest
```
### Upgrade this image
Bitnami provides up-to-date versions of PostgreSQL and SonarQube&trade;, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container. We will cover here the upgrade of the SonarQube&trade; container. For the PostgreSQL upgrade see: <https://github.com/bitnami/containers/tree/main/bitnami/postgresql#user-content-upgrade-this-image>
The `bitnami/sonarqube:latest` tag always points to the most recent release. To get the most recent release you can simple repull the `latest` tag from the Docker Hub with `docker pull bitnami/sonarqube:latest`. However it is recommended to use [tagged versions](https://hub.docker.com/r/bitnami/sonarqube/tags/).
#### Step 1: Get the updated image
```console
docker pull bitnami/sonarqube:latest
```
#### Step 2: Stop the running container
Stop the currently running container using the command
```console
docker-compose stop sonarqube
```
#### Step 3: Take a snapshot of the application state
Follow the steps in [Backing up your container](#backing-up-your-container) to take a snapshot of the current application state.
#### Step 4: Remove the currently running container
Remove the currently running container by executing the following command:
```console
docker-compose rm -v sonarqube
```
#### Step 5: Run the new image
Update the image tag in `docker-compose.yml` and re-create your container with the new image:
```console
docker-compose up -d
```
## Notable Changes
### 9.0.0-debian-10-r0
* The size of the container image has been decreased.
* The configuration logic is now based on Bash scripts in the *rootfs/* folder.
* The SonarQube&trade; container image has been migrated to a "non-root" user approach. Previously the container ran as the `root` user and the SonarQube&trade; daemon was started as the `sonarqube` user. From now on, both the container and the SonarQube&trade; daemon run as user `1001`. You can revert this behavior by changing `USER 1001` to `USER root` in the Dockerfile, or `user: root` in `docker-compose.yml`. Consequences:
* Backwards compatibility is not guaranteed when data is persisted using docker or docker-compose. We highly recommend migrating the SonarQube&trade; site by exporting its content, and importing it on a new SonarQube&trade; container. Follow the steps in [Backing up your container](#backing-up-your-container) and [Restoring a backup](#restoring-a-backup) to migrate the data between the old and new container.
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

393
bitnami/spark/3.4/debian-12/README.md
View File

@@ -1,393 +0,0 @@
# Bitnami package for Apache Spark
## What is Apache Spark?
> Apache Spark is a high-performance engine for large-scale computing tasks, such as data processing, machine learning and real-time data streaming. It includes APIs for Java, Python, Scala and R.
[Overview of Apache Spark](https://spark.apache.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
### Docker Compose
```console
docker run --name spark bitnami/spark:latest
```
You can find the available configuration options in the [Environment Variables](#environment-variables) section.
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Apache Spark in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## How to deploy Apache Spark in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami Apache Spark Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/spark).
Bitnami containers can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Apache Spark Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/spark).
```console
docker pull bitnami/spark:latest
```
To use a specific version, you can pull a versioned tag. You can view the
[list of available versions](https://hub.docker.com/r/bitnami/spark/tags/)
in the Docker Hub Registry.
```console
docker pull bitnami/spark:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|------------------------------------------|----------------------------------------------------------------------------------|------------------------------------------------|
| `SPARK_MODE` | Spark cluster mode to run (can be master or worker). | `master` |
| `SPARK_MASTER_URL` | Url where the worker can find the master. Only needed when spark mode is worker. | `spark://spark-master:7077` |
| `SPARK_NO_DAEMONIZE` | Spark does not run as a daemon. | `true` |
| `SPARK_RPC_AUTHENTICATION_ENABLED` | Enable RPC authentication. | `no` |
| `SPARK_RPC_AUTHENTICATION_SECRET` | The secret key used for RPC authentication. | `nil` |
| `SPARK_RPC_ENCRYPTION_ENABLED` | Enable RPC encryption. | `no` |
| `SPARK_LOCAL_STORAGE_ENCRYPTION_ENABLED` | Enable local storage encryption. | `no` |
| `SPARK_SSL_ENABLED` | Enable SSL configuration. | `no` |
| `SPARK_SSL_KEY_PASSWORD` | The password to the private key in the key store. | `nil` |
| `SPARK_SSL_KEYSTORE_PASSWORD` | The password for the key store. | `nil` |
| `SPARK_SSL_KEYSTORE_FILE` | Location of the key store. | `${SPARK_CONF_DIR}/certs/spark-keystore.jks` |
| `SPARK_SSL_TRUSTSTORE_PASSWORD` | The password for the trust store. | `nil` |
| `SPARK_SSL_TRUSTSTORE_FILE` | Location of the key store. | `${SPARK_CONF_DIR}/certs/spark-truststore.jks` |
| `SPARK_SSL_NEED_CLIENT_AUTH` | Whether to require client authentication. | `yes` |
| `SPARK_SSL_PROTOCOL` | TLS protocol to use. | `TLSv1.2` |
| `SPARK_WEBUI_SSL_PORT` | Spark management server port number for SSL/TLS connections. | `nil` |
| `SPARK_METRICS_ENABLED` | Whether to enable metrics for Spark. | `false` |
#### Read-only environment variables
| Name | Description | Value |
|--------------------------|----------------------------------------|-----------------------------------------|
| `SPARK_BASE_DIR` | Spark installation directory. | `${BITNAMI_ROOT_DIR}/spark` |
| `SPARK_CONF_DIR` | Spark configuration directory. | `${SPARK_BASE_DIR}/conf` |
| `SPARK_DEFAULT_CONF_DIR` | Spark default configuration directory. | `${SPARK_BASE_DIR}/conf.default` |
| `SPARK_WORK_DIR` | Spark workspace directory. | `${SPARK_BASE_DIR}/work` |
| `SPARK_CONF_FILE` | Spark configuration file path. | `${SPARK_CONF_DIR}/spark-defaults.conf` |
| `SPARK_LOG_DIR` | Spark logs directory. | `${SPARK_BASE_DIR}/logs` |
| `SPARK_TMP_DIR` | Spark tmp directory. | `${SPARK_BASE_DIR}/tmp` |
| `SPARK_JARS_DIR` | Spark jar directory. | `${SPARK_BASE_DIR}/jars` |
| `SPARK_INITSCRIPTS_DIR` | Spark init scripts directory. | `/docker-entrypoint-initdb.d` |
| `SPARK_USER` | Spark user. | `spark` |
| `SPARK_DAEMON_USER` | Spark system user. | `spark` |
| `SPARK_DAEMON_GROUP` | Spark system group. | `spark` |
Additionally, more environment variables natively supported by Apache Spark can be found [at the official documentation](https://spark.apache.org/docs/latest/spark-standalone.html#cluster-launch-scripts).
For example, you could still use `SPARK_WORKER_CORES` or `SPARK_WORKER_MEMORY` to configure the number of cores and the amount of memory to be used by a worker machine.
When you start the spark image, you can adjust the configuration of the instance by passing one or more environment variables either on the docker-compose file or on the `docker run` command line. If you want to add a new environment variable:
* For docker-compose add the variable name and value under the application section in the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/spark/docker-compose.yml) file present in this repository:
```yaml
spark:
...
environment:
- SPARK_MODE=master
...
```
* For manual execution add a -e option with each variable and value:
```console
docker run -d --name spark \
--network=spark_network \
-e SPARK_MODE=master \
bitnami/spark
```
### Security
The Bitnani Apache Spark docker image supports enabling RPC authentication, RPC encryption and local storage encryption easily using the following env vars in all the nodes of the cluster.
```diff
+ SPARK_RPC_AUTHENTICATION_ENABLED=yes
+ SPARK_RPC_AUTHENTICATION_SECRET=RPC_AUTHENTICATION_SECRET
+ SPARK_RPC_ENCRYPTION=yes
+ SPARK_LOCAL_STORAGE_ENCRYPTION=yes
```
> Please note that `RPC_AUTHENTICATION_SECRET` is a placeholder that needs to be updated with a correct value.
> Be also aware that currently is not possible to submit an application to a standalone cluster if RPC authentication is configured. More info about the issue [here](https://issues.apache.org/jira/browse/SPARK-25078).
Additionally, SSL configuration can be easily activated following the next steps:
1. Enable SSL configuration by setting the following env vars:
```diff
+ SPARK_SSL_ENABLED=yes
+ SPARK_SSL_KEY_PASSWORD=KEY_PASSWORD
+ SPARK_SSL_KEYSTORE_PASSWORD=KEYSTORE_PASSWORD
+ SPARK_SSL_TRUSTSTORE_PASSWORD=TRUSTSTORE_PASSWORD
+ SPARK_SSL_NEED_CLIENT_AUTH=yes
+ SPARK_SSL_PROTOCOL=TLSv1.2
```
> Please note that `KEY_PASSWORD`, `KEYSTORE_PASSWORD`, and `TRUSTSTORE_PASSWORD` are placeholders that needs to be updated with a correct value.
2. You need to mount your spark keystore and truststore files to `/opt/bitnami/spark/conf/certs`. Please note they should be called `spark-keystore.jks` and `spark-truststore.jks` and they should be in JKS format.
### Setting up an Apache Spark Cluster
A Apache Spark cluster can easily be setup with the default docker-compose.yml file from the root of this repo. The docker-compose includes two different services, `spark-master` and `spark-worker.`
By default, when you deploy the docker-compose file you will get an Apache Spark cluster with 1 master and 1 worker.
If you want N workers, all you need to do is start the docker-compose deployment with the following command:
```console
docker-compose up --scale spark-worker=3
```
### Mount a custom configuration file
The image looks for configuration in the `conf/` directory of `/opt/bitnami/spark`.
#### Using docker-compose
```yaml
...
volumes:
- /path/to/spark-defaults.conf:/opt/bitnami/spark/conf/spark-defaults.conf
...
```
#### Using the command line
```console
docker run --name spark -v /path/to/spark-defaults.conf:/opt/bitnami/spark/conf/spark-defaults.conf bitnami/spark:latest
```
After that, your changes will be taken into account in the server's behaviour.
### Installing additional jars
By default, this container bundles a generic set of jar files but the default image can be extended to add as many jars as needed for your specific use case. For instance, the following Dockerfile adds [`aws-java-sdk-bundle-1.11.704.jar`](https://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk-bundle/1.11.704):
```Dockerfile
FROM bitnami/spark
USER root
RUN install_packages curl
USER 1001
RUN curl https://repo1.maven.org/maven2/com/amazonaws/aws-java-sdk-bundle/1.11.704/aws-java-sdk-bundle-1.11.704.jar --output /opt/bitnami/spark/jars/aws-java-sdk-bundle-1.11.704.jar
```
#### Using a different version of Hadoop jars
In a similar way that in the previous section, you may want to use a different version of Hadoop jars.
Go to <https://spark.apache.org/downloads.html> and copy the download url bundling the Hadoop version you want and matching the Apache Spark version of the container. Extend the Bitnami container image as below:
```Dockerfile
FROM bitnami/spark:3.5.0
USER root
RUN install_packages curl
USER 1001
RUN rm -r /opt/bitnami/spark/jars && \
curl --location https://dlcdn.apache.org/spark/spark-3.5.0/spark-3.5.0-bin-hadoop3.tgz | \
tar --extract --gzip --strip=1 --directory /opt/bitnami/spark/ spark-3.5.0-bin-hadoop3/jars/
```
You can check the Hadoop version by running the following commands in the new container image:
```console
$ pyspark
>>> sc._gateway.jvm.org.apache.hadoop.util.VersionInfo.getVersion()
'2.7.4'
```
## Logging
The Bitnami Apache Spark Docker image sends the container logs to the `stdout`. To view the logs:
```console
docker logs spark
```
or using Docker Compose:
```console
docker-compose logs spark
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Maintenance
### Backing up your container
To backup your data, configuration and logs, follow these simple steps:
#### Step 1: Stop the currently running container
```console
docker stop spark
```
or using Docker Compose:
```console
docker-compose stop spark
```
#### Step 2: Run the backup command
We need to mount two volumes in a container we will use to create the backup: a directory on your host to store the backup in, and the volumes from the container we just stopped so we can access the data.
```console
docker run --rm -v /path/to/spark-backups:/backups --volumes-from spark busybox \
cp -a /bitnami/spark /backups/latest
```
or using Docker Compose:
```console
docker run --rm -v /path/to/spark-backups:/backups --volumes-from `docker-compose ps -q spark` busybox \
cp -a /bitnami/spark /backups/latest
```
### Restoring a backup
Restoring a backup is as simple as mounting the backup as volumes in the container.
```console
docker run -v /path/to/spark-backups/latest:/bitnami/spark bitnami/spark:latest
```
or by modifying the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/spark/docker-compose.yml) file present in this repository:
```yaml
services:
spark:
...
volumes:
- /path/to/spark-backups/latest:/bitnami/spark
...
```
### Upgrade this image
Bitnami provides up-to-date versions of spark, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/spark:latest
```
or if you're using Docker Compose, update the value of the image property to
`bitnami/spark:latest`.
#### Step 2: Stop and backup the currently running container
Before continuing, you should backup your container's data, configuration and logs.
Follow the steps on [creating a backup](#backing-up-your-container).
#### Step 3: Remove the currently running container
```console
docker rm -v spark
```
or using Docker Compose:
```console
docker-compose rm -v spark
```
#### Step 4: Run the new image
Re-create your container from the new image, [restoring your backup](#restoring-a-backup) if necessary.
```console
docker run --name spark bitnami/spark:latest
```
or using Docker Compose:
```console
docker-compose up spark
```
## Notable Changes
### 3.0.0-debian-10-r44
* The container image was updated to use Hadoop `3.2.x`. If you want to use a different version, please read [Using a different version of Hadoop jars](#using-a-different-version-of-hadoop-jars).
### 2.4.5-debian-10-r49
* This image now has an aws-cli and two jars: hadoop-aws and aws-java-sdk for provide an easier way to use AWS.
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/spark).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

393
bitnami/spark/3.5/debian-12/README.md
View File

@@ -1,393 +0,0 @@
# Bitnami package for Apache Spark
## What is Apache Spark?
> Apache Spark is a high-performance engine for large-scale computing tasks, such as data processing, machine learning and real-time data streaming. It includes APIs for Java, Python, Scala and R.
[Overview of Apache Spark](https://spark.apache.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
### Docker Compose
```console
docker run --name spark bitnami/spark:latest
```
You can find the available configuration options in the [Environment Variables](#environment-variables) section.
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Apache Spark in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## How to deploy Apache Spark in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami Apache Spark Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/spark).
Bitnami containers can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Apache Spark Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/spark).
```console
docker pull bitnami/spark:latest
```
To use a specific version, you can pull a versioned tag. You can view the
[list of available versions](https://hub.docker.com/r/bitnami/spark/tags/)
in the Docker Hub Registry.
```console
docker pull bitnami/spark:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|------------------------------------------|----------------------------------------------------------------------------------|------------------------------------------------|
| `SPARK_MODE` | Spark cluster mode to run (can be master or worker). | `master` |
| `SPARK_MASTER_URL` | Url where the worker can find the master. Only needed when spark mode is worker. | `spark://spark-master:7077` |
| `SPARK_NO_DAEMONIZE` | Spark does not run as a daemon. | `true` |
| `SPARK_RPC_AUTHENTICATION_ENABLED` | Enable RPC authentication. | `no` |
| `SPARK_RPC_AUTHENTICATION_SECRET` | The secret key used for RPC authentication. | `nil` |
| `SPARK_RPC_ENCRYPTION_ENABLED` | Enable RPC encryption. | `no` |
| `SPARK_LOCAL_STORAGE_ENCRYPTION_ENABLED` | Enable local storage encryption. | `no` |
| `SPARK_SSL_ENABLED` | Enable SSL configuration. | `no` |
| `SPARK_SSL_KEY_PASSWORD` | The password to the private key in the key store. | `nil` |
| `SPARK_SSL_KEYSTORE_PASSWORD` | The password for the key store. | `nil` |
| `SPARK_SSL_KEYSTORE_FILE` | Location of the key store. | `${SPARK_CONF_DIR}/certs/spark-keystore.jks` |
| `SPARK_SSL_TRUSTSTORE_PASSWORD` | The password for the trust store. | `nil` |
| `SPARK_SSL_TRUSTSTORE_FILE` | Location of the key store. | `${SPARK_CONF_DIR}/certs/spark-truststore.jks` |
| `SPARK_SSL_NEED_CLIENT_AUTH` | Whether to require client authentication. | `yes` |
| `SPARK_SSL_PROTOCOL` | TLS protocol to use. | `TLSv1.2` |
| `SPARK_WEBUI_SSL_PORT` | Spark management server port number for SSL/TLS connections. | `nil` |
| `SPARK_METRICS_ENABLED` | Whether to enable metrics for Spark. | `false` |
#### Read-only environment variables
| Name | Description | Value |
|--------------------------|----------------------------------------|-----------------------------------------|
| `SPARK_BASE_DIR` | Spark installation directory. | `${BITNAMI_ROOT_DIR}/spark` |
| `SPARK_CONF_DIR` | Spark configuration directory. | `${SPARK_BASE_DIR}/conf` |
| `SPARK_DEFAULT_CONF_DIR` | Spark default configuration directory. | `${SPARK_BASE_DIR}/conf.default` |
| `SPARK_WORK_DIR` | Spark workspace directory. | `${SPARK_BASE_DIR}/work` |
| `SPARK_CONF_FILE` | Spark configuration file path. | `${SPARK_CONF_DIR}/spark-defaults.conf` |
| `SPARK_LOG_DIR` | Spark logs directory. | `${SPARK_BASE_DIR}/logs` |
| `SPARK_TMP_DIR` | Spark tmp directory. | `${SPARK_BASE_DIR}/tmp` |
| `SPARK_JARS_DIR` | Spark jar directory. | `${SPARK_BASE_DIR}/jars` |
| `SPARK_INITSCRIPTS_DIR` | Spark init scripts directory. | `/docker-entrypoint-initdb.d` |
| `SPARK_USER` | Spark user. | `spark` |
| `SPARK_DAEMON_USER` | Spark system user. | `spark` |
| `SPARK_DAEMON_GROUP` | Spark system group. | `spark` |
Additionally, more environment variables natively supported by Apache Spark can be found [at the official documentation](https://spark.apache.org/docs/latest/spark-standalone.html#cluster-launch-scripts).
For example, you could still use `SPARK_WORKER_CORES` or `SPARK_WORKER_MEMORY` to configure the number of cores and the amount of memory to be used by a worker machine.
When you start the spark image, you can adjust the configuration of the instance by passing one or more environment variables either on the docker-compose file or on the `docker run` command line. If you want to add a new environment variable:
* For docker-compose add the variable name and value under the application section in the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/spark/docker-compose.yml) file present in this repository:
```yaml
spark:
...
environment:
- SPARK_MODE=master
...
```
* For manual execution add a -e option with each variable and value:
```console
docker run -d --name spark \
--network=spark_network \
-e SPARK_MODE=master \
bitnami/spark
```
### Security
The Bitnani Apache Spark docker image supports enabling RPC authentication, RPC encryption and local storage encryption easily using the following env vars in all the nodes of the cluster.
```diff
+ SPARK_RPC_AUTHENTICATION_ENABLED=yes
+ SPARK_RPC_AUTHENTICATION_SECRET=RPC_AUTHENTICATION_SECRET
+ SPARK_RPC_ENCRYPTION=yes
+ SPARK_LOCAL_STORAGE_ENCRYPTION=yes
```
> Please note that `RPC_AUTHENTICATION_SECRET` is a placeholder that needs to be updated with a correct value.
> Be also aware that currently is not possible to submit an application to a standalone cluster if RPC authentication is configured. More info about the issue [here](https://issues.apache.org/jira/browse/SPARK-25078).
Additionally, SSL configuration can be easily activated following the next steps:
1. Enable SSL configuration by setting the following env vars:
```diff
+ SPARK_SSL_ENABLED=yes
+ SPARK_SSL_KEY_PASSWORD=KEY_PASSWORD
+ SPARK_SSL_KEYSTORE_PASSWORD=KEYSTORE_PASSWORD
+ SPARK_SSL_TRUSTSTORE_PASSWORD=TRUSTSTORE_PASSWORD
+ SPARK_SSL_NEED_CLIENT_AUTH=yes
+ SPARK_SSL_PROTOCOL=TLSv1.2
```
> Please note that `KEY_PASSWORD`, `KEYSTORE_PASSWORD`, and `TRUSTSTORE_PASSWORD` are placeholders that needs to be updated with a correct value.
2. You need to mount your spark keystore and truststore files to `/opt/bitnami/spark/conf/certs`. Please note they should be called `spark-keystore.jks` and `spark-truststore.jks` and they should be in JKS format.
### Setting up an Apache Spark Cluster
A Apache Spark cluster can easily be setup with the default docker-compose.yml file from the root of this repo. The docker-compose includes two different services, `spark-master` and `spark-worker.`
By default, when you deploy the docker-compose file you will get an Apache Spark cluster with 1 master and 1 worker.
If you want N workers, all you need to do is start the docker-compose deployment with the following command:
```console
docker-compose up --scale spark-worker=3
```
### Mount a custom configuration file
The image looks for configuration in the `conf/` directory of `/opt/bitnami/spark`.
#### Using docker-compose
```yaml
...
volumes:
- /path/to/spark-defaults.conf:/opt/bitnami/spark/conf/spark-defaults.conf
...
```
#### Using the command line
```console
docker run --name spark -v /path/to/spark-defaults.conf:/opt/bitnami/spark/conf/spark-defaults.conf bitnami/spark:latest
```
After that, your changes will be taken into account in the server's behaviour.
### Installing additional jars
By default, this container bundles a generic set of jar files but the default image can be extended to add as many jars as needed for your specific use case. For instance, the following Dockerfile adds [`aws-java-sdk-bundle-1.11.704.jar`](https://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk-bundle/1.11.704):
```Dockerfile
FROM bitnami/spark
USER root
RUN install_packages curl
USER 1001
RUN curl https://repo1.maven.org/maven2/com/amazonaws/aws-java-sdk-bundle/1.11.704/aws-java-sdk-bundle-1.11.704.jar --output /opt/bitnami/spark/jars/aws-java-sdk-bundle-1.11.704.jar
```
#### Using a different version of Hadoop jars
In a similar way that in the previous section, you may want to use a different version of Hadoop jars.
Go to <https://spark.apache.org/downloads.html> and copy the download url bundling the Hadoop version you want and matching the Apache Spark version of the container. Extend the Bitnami container image as below:
```Dockerfile
FROM bitnami/spark:3.5.0
USER root
RUN install_packages curl
USER 1001
RUN rm -r /opt/bitnami/spark/jars && \
curl --location https://dlcdn.apache.org/spark/spark-3.5.0/spark-3.5.0-bin-hadoop3.tgz | \
tar --extract --gzip --strip=1 --directory /opt/bitnami/spark/ spark-3.5.0-bin-hadoop3/jars/
```
You can check the Hadoop version by running the following commands in the new container image:
```console
$ pyspark
>>> sc._gateway.jvm.org.apache.hadoop.util.VersionInfo.getVersion()
'2.7.4'
```
## Logging
The Bitnami Apache Spark Docker image sends the container logs to the `stdout`. To view the logs:
```console
docker logs spark
```
or using Docker Compose:
```console
docker-compose logs spark
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Maintenance
### Backing up your container
To backup your data, configuration and logs, follow these simple steps:
#### Step 1: Stop the currently running container
```console
docker stop spark
```
or using Docker Compose:
```console
docker-compose stop spark
```
#### Step 2: Run the backup command
We need to mount two volumes in a container we will use to create the backup: a directory on your host to store the backup in, and the volumes from the container we just stopped so we can access the data.
```console
docker run --rm -v /path/to/spark-backups:/backups --volumes-from spark busybox \
cp -a /bitnami/spark /backups/latest
```
or using Docker Compose:
```console
docker run --rm -v /path/to/spark-backups:/backups --volumes-from `docker-compose ps -q spark` busybox \
cp -a /bitnami/spark /backups/latest
```
### Restoring a backup
Restoring a backup is as simple as mounting the backup as volumes in the container.
```console
docker run -v /path/to/spark-backups/latest:/bitnami/spark bitnami/spark:latest
```
or by modifying the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/spark/docker-compose.yml) file present in this repository:
```yaml
services:
spark:
...
volumes:
- /path/to/spark-backups/latest:/bitnami/spark
...
```
### Upgrade this image
Bitnami provides up-to-date versions of spark, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/spark:latest
```
or if you're using Docker Compose, update the value of the image property to
`bitnami/spark:latest`.
#### Step 2: Stop and backup the currently running container
Before continuing, you should backup your container's data, configuration and logs.
Follow the steps on [creating a backup](#backing-up-your-container).
#### Step 3: Remove the currently running container
```console
docker rm -v spark
```
or using Docker Compose:
```console
docker-compose rm -v spark
```
#### Step 4: Run the new image
Re-create your container from the new image, [restoring your backup](#restoring-a-backup) if necessary.
```console
docker run --name spark bitnami/spark:latest
```
or using Docker Compose:
```console
docker-compose up spark
```
## Notable Changes
### 3.0.0-debian-10-r44
* The container image was updated to use Hadoop `3.2.x`. If you want to use a different version, please read [Using a different version of Hadoop jars](#using-a-different-version-of-hadoop-jars).
### 2.4.5-debian-10-r49
* This image now has an aws-cli and two jars: hadoop-aws and aws-java-sdk for provide an easier way to use AWS.
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/spark).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

157
bitnami/supabase-realtime/2/debian-12/README.md
View File

@@ -1,157 +0,0 @@
# Bitnami package for Supabase Realtime
## What is Supabase Realtime?
> Supabase Realtime is a component of Supabase. Supabase is an open source implementation of Firebase. Supabase Realtime tracks and synchronizes changes in PostgreSQL instances using Websockets.
[Overview of Supabase Realtime](https://github.com/supabase/realtime)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run -it --name supabase-realtime bitnami/supabase-realtime
```
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Supabase Realtime in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Supabase Realtime Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/supabase-realtime).
```console
docker pull bitnami/supabase-realtime:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/supabase-realtime/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/supabase-realtime:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of Supabase Realtime, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/supabase-realtime:latest
```
#### Step 2: Remove the currently running container
```console
docker rm -v supabase-realtime
```
#### Step 3: Run the new image
Re-create your container from the new image.
```console
docker run --name supabase-realtime bitnami/supabase-realtime:latest
```
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|-----------------------------|---------------------------------|-------------------------|
| `DB_HOST` | Database host | `localhost` |
| `DB_PORT` | Database port number | `5432` |
| `DB_NAME` | Database name | `postgres` |
| `DB_USER` | Database user username | `postgres` |
| `DB_PASSWORD` | Database password | `nil` |
| `DB_SSL` | Database SSL connection enabled | `disable` |
| `API_JWT_SECRET` | API Secret | `nil` |
| `SECRET_KEY_BASE` | Key Base Secret | `nil` |
| `PORT` | Service Port | `9500` |
| `APP_NAME` | App Name | `realtime` |
| `ERL_AFLAGS` | Flags | `-proto_dist inet_tcp` |
| `REPLICATION_MODE` | Replication Mode | `RLS` |
| `REPLICATION_POLL_INTERVAL` | Replication pool interval | `100` |
| `SECURE_CHANNELS` | Secure channels | `true` |
| `SLOT_NAME` | Slot name | `supabase_realtime_rls` |
| `TEMPORARY_SLOT` | Temporary Slot | `true` |
#### Read-only environment variables
| Name | Description | Value |
|----------------------------------|-----------------------------------------------------|-------------------------------------------------------|
| `SUPABASE_REALTIME_BASE_DIR` | Supabase-realtime installation directory. | `${BITNAMI_ROOT_DIR}/supabase-realtime` |
| `SUPABASE_REALTIME_LOGS_DIR` | Directory where Supabase-realtime logs are stored. | `${SUPABASE_REALTIME_BASE_DIR}/logs` |
| `SUPABASE_REALTIME_LOG_FILE` | Directory where Supabase-realtime logs are stored. | `${SUPABASE_REALTIME_LOGS_DIR}/supabase-realtime.log` |
| `SUPABASE_REALTIME_BIN_DIR` | Supabase-realtime directory for binary executables. | `${SUPABASE_REALTIME_BASE_DIR}/bin` |
| `SUPABASE_REALTIME_DAEMON_USER` | postgrest system user. | `supabase` |
| `SUPABASE_REALTIME_DAEMON_GROUP` | postgrest system group. | `supabase` |
### Running commands
To run commands inside this container you can use `docker run`, for example to execute `supabase-realtime --help` you can follow the example below:
```console
docker run --rm --name supabase-realtime bitnami/supabase-realtime:latest --help
```
Check the [official Supabase Realtime documentation](https://github.com/supabase/realtime) for more information about how to use Supabase Realtime.
## Notable Changes
### Starting January 16, 2024
* The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes.
## Contributing
We'd love for you to contribute to this Docker image. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.

357
bitnami/tomcat/10.1/debian-12/README.md
View File

@@ -1,357 +0,0 @@
# Bitnami package for Apache Tomcat
## What is Apache Tomcat?
> Apache Tomcat is an open-source web server designed to host and run Java-based web applications. It is a lightweight server with a good performance for applications running in production environments.
[Overview of Apache Tomcat](http://tomcat.apache.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
## TL;DR
```console
docker run --name tomcat bitnami/tomcat:latest
```
You can find the default credentials and available configuration options in the [Environment Variables](#environment-variables) section.
## Why use Bitnami Images?
* Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
* With Bitnami images the latest bug fixes and features are available as soon as possible.
* Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
* All our images are based on [**minideb**](https://github.com/bitnami/minideb) -a minimalist Debian based container image that gives you a small base container image and the familiarity of a leading Linux distribution- or **scratch** -an explicitly empty image-.
* All Bitnami images available in Docker Hub are signed with [Notation](https://notaryproject.dev/). [Check this post](https://blog.bitnami.com/2024/03/bitnami-packaged-containers-and-helm.html) to know how to verify the integrity of the images.
* Bitnami container images are released on a regular basis with the latest distribution packages available.
Looking to use Apache Tomcat in production? Try [VMware Tanzu Application Catalog](https://bitnami.com/enterprise), the commercial edition of the Bitnami catalog.
## How to deploy Apache Apache Tomcat in Kubernetes?
Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami Apache Apache Tomcat Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/tomcat).
Bitnami containers can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Why use a non-root container?
Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-work-with-non-root-containers-index.html).
## Supported tags and respective `Dockerfile` links
Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html).
You can see the equivalence between the different tags by taking a look at the `tags-info.yaml` file present in the branch folder, i.e `bitnami/ASSET/BRANCH/DISTRO/tags-info.yaml`.
Subscribe to project updates by watching the [bitnami/containers GitHub repo](https://github.com/bitnami/containers).
## Get this image
The recommended way to get the Bitnami Apache Tomcat Docker Image is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/tomcat).
```console
docker pull bitnami/tomcat:latest
```
To use a specific version, you can pull a versioned tag. You can view the [list of available versions](https://hub.docker.com/r/bitnami/tomcat/tags/) in the Docker Hub Registry.
```console
docker pull bitnami/tomcat:[TAG]
```
If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile and executing the `docker build` command. Remember to replace the `APP`, `VERSION` and `OPERATING-SYSTEM` path placeholders in the example command below with the correct values.
```console
git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP:latest .
```
## Persisting your application
If you remove the container all your data and configurations will be lost, and the next time you run the image the database will be reinitialized. To avoid this loss of data, you should mount a volume that will persist even after the container is removed.
For persistence you should mount a directory at the `/bitnami` path. If the mounted directory is empty, it will be initialized on the first run.
```console
docker run -v /path/to/tomcat-persistence:/bitnami bitnami/tomcat:latest
```
Alternatively, modify the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/tomcat/docker-compose.yml) file present in this repository:
```yaml
services:
tomcat:
...
volumes:
- /path/to/tomcat-persistence:/bitnami
...
```
> NOTE: As this is a non-root container, the mounted files and directories must have the proper permissions for the UID `1001`.
## Deploying web applications on Apache Tomcat
The `/bitnami/tomcat/data` directory is configured as the Apache Tomcat webapps deployment directory. At this location, you either copy a so-called *exploded web application*, i.e. non-compressed, or a compressed web application resource (`.WAR`) file and it will automatically be deployed by Apache Tomcat.
Additionally a helper symlink `/app` is present that points to the webapps deployment directory which enables us to deploy applications on a running Apache Tomcat instance by simply doing:
```console
docker cp /path/to/app.war tomcat:/app
```
In case you want to create a custom image that already contains your application war file, you need to add it to the `/opt/bitnami/tomcat/webapps` folder. In the example below we create a forked image with an extra `.war` file.
```Dockerfile
FROM bitnami/tomcat:9.0
COPY sample.war /opt/bitnami/tomcat/webapps
```
**Note!**
You can also deploy web applications on a running Apache Tomcat instance using the Apache Tomcat management interface.
**Further Reading:**
* [Apache Tomcat Web Application Deployment](https://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html)
## Accessing your Apache Tomcat server from the host
To access your web server from your host machine you can ask Docker to map a random port on your host to port `8080` exposed in the container.
```console
docker run --name tomcat -P bitnami/tomcat:latest
```
Run `docker port` to determine the random ports Docker assigned.
```console
$ docker port tomcat
8080/tcp -> 0.0.0.0:32768
```
You can also manually specify the ports you want forwarded from your host to the container.
```console
docker run -p 8080:8080 bitnami/tomcat:latest
```
Access your web server in the browser by navigating to `http://localhost:8080`.
## Configuration
### Environment variables
#### Customizable environment variables
| Name | Description | Default Value |
|----------------------------------|---------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `TOMCAT_SHUTDOWN_PORT_NUMBER` | Tomcat shutdown port number. | `8005` |
| `TOMCAT_HTTP_PORT_NUMBER` | Tomcat HTTP port number. | `8080` |
| `TOMCAT_AJP_PORT_NUMBER` | Tomcat AJP port number. | `8009` |
| `TOMCAT_USERNAME` | Tomcat username. | `manager` |
| `TOMCAT_PASSWORD` | Tomcat password. | `nil` |
| `TOMCAT_ALLOW_REMOTE_MANAGEMENT` | Whether to allow connections from remote addresses to the Tomcat manager application. | `yes` |
| `TOMCAT_ENABLE_AUTH` | Whether to enable authentication for Tomcat manager applications. | `yes` |
| `TOMCAT_ENABLE_AJP` | Whether to enable the Tomcat AJP connector. | `no` |
| `TOMCAT_START_RETRIES` | The number or retries while waiting for Catalina to start. | `12` |
| `TOMCAT_EXTRA_JAVA_OPTS` | Additional Java settings for Tomcat. | `nil` |
| `TOMCAT_INSTALL_DEFAULT_WEBAPPS` | Whether to add default webapps (ROOT, manager, host-manager, etc.) for deployment. | `yes` |
| `JAVA_OPTS` | Java runtime parameters. | `-Djava.awt.headless=true -XX:+UseG1GC -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses=true -Duser.home=${TOMCAT_HOME}` |
#### Read-only environment variables
| Name | Description | Value |
|---------------------------|----------------------------------------------------|---------------------------------------|
| `TOMCAT_BASE_DIR` | Tomcat installation directory. | `${BITNAMI_ROOT_DIR}/tomcat` |
| `TOMCAT_VOLUME_DIR` | Tomcat persistence directory. | `/bitnami/tomcat` |
| `TOMCAT_BIN_DIR` | Tomcat directory for binary files. | `${TOMCAT_BASE_DIR}/bin` |
| `TOMCAT_LIB_DIR` | Tomcat directory for library files. | `${TOMCAT_BASE_DIR}/lib` |
| `TOMCAT_WORK_DIR` | Tomcat directory for runtime files. | `${TOMCAT_BASE_DIR}/work` |
| `TOMCAT_WEBAPPS_DIR` | Tomcat directory where webapps are stored. | `${TOMCAT_VOLUME_DIR}/webapps` |
| `TOMCAT_CONF_DIR` | Tomcat configuration directory. | `${TOMCAT_BASE_DIR}/conf` |
| `TOMCAT_DEFAULT_CONF_DIR` | Tomcat default configuration directory. | `${TOMCAT_BASE_DIR}/conf.default` |
| `TOMCAT_CONF_FILE` | Tomcat configuration file. | `${TOMCAT_CONF_DIR}/server.xml` |
| `TOMCAT_USERS_CONF_FILE` | Tomcat configuration file. | `${TOMCAT_CONF_DIR}/tomcat-users.xml` |
| `TOMCAT_LOGS_DIR` | Directory where Tomcat logs are stored. | `${TOMCAT_BASE_DIR}/logs` |
| `TOMCAT_TMP_DIR` | Directory where Tomcat temporary files are stored. | `${TOMCAT_BASE_DIR}/temp` |
| `TOMCAT_LOG_FILE` | Path to the log file for Tomcat. | `${TOMCAT_LOGS_DIR}/catalina.out` |
| `TOMCAT_PID_FILE` | Path to the PID file for Tomcat. | `${TOMCAT_TMP_DIR}/catalina.pid` |
| `TOMCAT_HOME` | Tomcat home directory. | `$TOMCAT_BASE_DIR` |
| `TOMCAT_DAEMON_USER` | Tomcat system user. | `tomcat` |
| `TOMCAT_DAEMON_GROUP` | Tomcat system group. | `tomcat` |
| `JAVA_HOME` | Java installation folder. | `${BITNAMI_ROOT_DIR}/java` |
#### Creating a custom user
By default, a management user named `manager` is created and is not assigned a password. Passing the `TOMCAT_PASSWORD` environment variable when running the image for the first time will set the password of this user to the value of `TOMCAT_PASSWORD`.
Additionally you can specify a user name for the management user using the `TOMCAT_USERNAME` environment variable. When not specified, the `TOMCAT_PASSWORD` configuration is applied on the default user (`manager`).
#### Specifying Environment variables using Docker Compose
This requires a minor change to the [`docker-compose.yml`](https://github.com/bitnami/containers/blob/main/bitnami/tomcat/docker-compose.yml) file present in this repository:
```yaml
services:
tomcat:
...
environment:
- TOMCAT_USERNAME=my_user
- TOMCAT_PASSWORD=my_password
...
```
#### Specifying Environment variables on the Docker command line
```console
docker run --name tomcat \
-e TOMCAT_USERNAME=my_user \
-e TOMCAT_PASSWORD=my_password \
bitnami/tomcat:latest
```
### Configuration files
During the initialization of the container, the default Apache Tomcat configuration files are modified with the basic options defined through [environment variables](#environment-variables). If you want to add more specific configuration options, you can always mount your own configuration files under `/opt/bitnami/tomcat/conf/` to override the existing ones. Please note that those files should be writable by the system user of the container.
```console
docker run --name tomcat -v /path/to/config/server.xml:/opt/bitnami/tomcat/conf/server.xml bitnami/tomcat:latest
```
or using Docker Compose:
```yaml
services:
tomcat:
...
volumes:
- /path/to/config/server.xml:/opt/bitnami/tomcat/conf/server.xml
...
```
Refer to the [Apache Tomcat configuration](https://tomcat.apache.org/tomcat-7.0-doc/config/index.html) manual for the complete list of configuration options.
## Logging
The Bitnami Apache Tomcat Docker image sends the container logs to the `stdout`. To view the logs:
```console
docker logs tomcat
```
or using Docker Compose:
```console
docker-compose logs tomcat
```
You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver.
## Maintenance
### Upgrade this image
Bitnami provides up-to-date versions of Apache Tomcat, including security patches, soon after they are made upstream. We recommend that you follow these steps to upgrade your container.
#### Step 1: Get the updated image
```console
docker pull bitnami/tomcat:latest
```
or if you're using Docker Compose, update the value of the image property to
`bitnami/tomcat:latest`.
#### Step 2: Stop and backup the currently running container
Stop the currently running container using the command
```console
docker stop tomcat
```
or using Docker Compose:
```console
docker-compose stop tomcat
```
Next, take a snapshot of the persistent volume `/path/to/tomcat-persistence` using:
```console
rsync -a /path/to/tomcat-persistence /path/to/tomcat-persistence.bkp.$(date +%Y%m%d-%H.%M.%S)
```
#### Step 3: Remove the currently running container
```console
docker rm -v tomcat
```
or using Docker Compose:
```console
docker-compose rm -v tomcat
```
#### Step 4: Run the new image
Re-create your container from the new image.
```console
docker run --name tomcat bitnami/tomcat:latest
```
or using Docker Compose:
```console
docker-compose up tomcat
```
## Notable Changes
### Debian: 9.0.26-r0, 8.5.46-r0, 8.0.53-r382, 7.0.96-r50. Oracle: 9.0.24-ol-7-r35, 8.5.45-ol-7-r34, 8.0.53-ol-7-r426, 7.0.96-ol-7-r61
* Decrease the size of the container. The configuration logic is now based on Bash scripts in the `rootfs/` folder.
### 9.0.13-r27 , 8.5.35-r26, 8.0.53-r131 & 7.0.92-r20
* The Apache Tomcat container has been migrated to a non-root user approach. Previously the container ran as the `root` user and the Apache Tomcat daemon was started as the `tomcat` user. From now on, both the container and the Apache Tomcat daemon run as user `1001`. As a consequence, the data directory must be writable by that user. You can revert this behavior by changing `USER 1001` to `USER root` in the Dockerfile.
### 8.0.35-r3
* `TOMCAT_USER` parameter has been renamed to `TOMCAT_USERNAME`.
### 8.0.35-r0
* All volumes have been merged at `/bitnami/tomcat`. Now you only need to mount a single volume at `/bitnami/tomcat` for persistence.
* The logs are always sent to the `stdout` and are no longer collected in the volume.
## Using `docker-compose.yaml`
Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/tomcat).
If you detect any issue in the `docker-compose.yaml` file, feel free to report it or contribute with a fix by following our [Contributing Guidelines](https://github.com/bitnami/containers/blob/main/CONTRIBUTING.md).
## Contributing
We'd love for you to contribute to this container. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues) or submitting a [pull request](https://github.com/bitnami/containers/pulls) with your contribution.
## Issues
If you encountered a problem running this container, you can file an [issue](https://github.com/bitnami/containers/issues/new/choose). For us to provide better support, be sure to fill the issue template.
## License
Copyright &copy; 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
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>
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.