podman outputs a lot of logs

[kmadridr]

I am running the command from https://docs.podman.io/en/latest/Introduction.html which is **podman search busybox
** and I am getting a lot of logs into the console.

/kind bug

Description

Steps to reproduce the issue:

1. The Podman i am using:
   Podman Engine
   Version: 4.0.3
   API Version: 4.0.3
   Go Version: go1.16.15
   Git Commit: 6253405
   Built: Mon Apr 4 10:34:42 2022
   OS/Arch: windows/amd64

Server: Podman Engine
Version: 4.0.3
API Version: 4.0.3
Go Version: go1.16.15
Built: Fri Apr 1 11:21:14 2022
OS/Arch: linux/amd64

Describe the results you received:
time="2022-04-27T15:33:48-07:00" level=warning msg="Failed to retrieve default tmp dir: invalid image_copy_tmp_dir value "/var/tmp" (relative paths are not accepted)" NAME DESCRIPTION docker.io/library/busybox Busybox base image. docker.io/rancher/busybox docker.io/ibmcom/busybox docker.io/ibmcom/busybox-amd64 docker.io/ibmcom/busybox-ppc64le docker.io/yauritux/busybox-curl Busybox with CURL docker.io/vukomir/busybox busybox and curl docker.io/radial/busyboxplus Full-chain, Internet enabled, busybox made from scratch. Comes in git and cURL flavors. docker.io/busybox42/zimbra-docker-centos A Zimbra Docker image, based in ZCS 8.8.9 and CentOS 7. docker.io/arm64v8/busybox Busybox base image. docker.io/odise/busybox-curl docker.io/amd64/busybox Busybox base image. docker.io/joeshaw/busybox-nonroot Busybox container with non-root user nobody docker.io/ppc64le/busybox Busybox base image. docker.io/busybox42/alpine-pod docker.io/p7ppc64/busybox Busybox base image for ppc64. docker.io/busybox42/haraka-docker-centos CentOS Haraka build with spamassassin, redis and some other things. Experimental still.. docker.io/s390x/busybox Busybox base image. docker.io/busybox42/nginx_php-docker-centos This is a nginx/php-fpm server running on CentOS 7. docker.io/prom/busybox Prometheus Busybox Docker base images docker.io/arm32v7/busybox Busybox base image. docker.io/busybox42/php-fpm-ldap docker.io/i386/busybox Busybox base image. docker.io/spotify/busybox Spotify fork of https://hub.docker.com/_/busybox/ for testing helios.docker.io/busybox42/bind-docker-centos This is a bind server running on CentOS 7. quay.io/prometheus/busybox # Prometheus Busybox Docker Base Images ## Tags ### prom/busybox:latest : uClibc Based on the official busybox:uclibc base image. The following files are added (taken from Debian) to fix some common issues: - /etc/ssl/certs/ca-certificates.crt : for HTTS support - /usr/share/zoneinfo : for timezones ### prom/busybox:glibc : glibc Based on the official busybox:glibc base image. The following files are added (taken from Debian) to fix some common issues: - /etc/ssl/certs/ca-certificates.crt : for HTTS support - /usr/share/zoneinfo : for timezones - /lib/x86_64-linux-gnu/libpthread.so.0 : common required lib for project binaries that cannot be statically builded. ## Update build dependencies $ git clone https://github.com/prometheus/busybox.git $ make deps ## Build Docker images locally $ git clone https://github.com/prometheus/busybox.git $ make build ## More information * All of the core developers are accessible via the Prometheus Developers Mailinglist and the #prometheus channel on irc.freenode.net. ## Contributing Refer to CONTRIBUTING.md ## License Apache License 2.0, see LICENSE. quay.io/libpod/busybox quay.io/domino/busybox quay.io/quay/busybox Busybox base image. quay.io/sisense/busybox quay.io/asmacdo/busybox quay.io/openshifttest/busybox quay.io/sjenning/busybox quay.io/bioconda/base-glibc-busybox-bash quay.io/56401deb-7290-4d8b-8731-baf6d8b5d27d/postgresql Official build of Bitnami PostgreSQL. View README for details. # What is PostgreSQL? > PostgreSQL is an object-relational database management system (ORDBMS) with an emphasis on extensibility and on standards-compliance [source]. # TL;DR; bash docker run --name postgresql bitnami/postgresql:latest ## Docker Compose yaml version: '2' services: postgresql: image: 'bitnami/postgresql:latest' ports: - '5432:5432' ## Kubernetes > WARNING: This is a beta configuration, currently unsupported. Get the raw URL pointing to the kubernetes.yml manifest and use kubectl to create the resources on your Kubernetes cluster like so: bash $ kubectl create -f https://raw.githubusercontent.com/bitnami/bitnami-docker-postgresql/master/kubernetes.yml # 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. * Bitnami images are built on CircleCI and automatically pushed to the Docker Hub. * All our images are based on minideb a minimalist Debian based container image which gives you a small base container image and the familiarity of a leading linux distribution. # Get this image The recommended way to get the Bitnami PostgreSQL Docker Image is to pull the prebuilt image from the Docker Hub Registry. bash docker pull bitnami/postgresql:latest To use a specific version, you can pull a versioned tag. You can view the list of available versions in the Docker Hub Registry. bash docker pull bitnami/postgresql:[TAG] If you wish, you can also build the image yourself. bash docker build -t bitnami/postgresql:latest https://github.com/bitnami/bitnami-docker-postgresql.git # Persisting your database 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. Note! If you have already started using your database, follow the steps on backing up and restoring to pull the data from your running container down to your host. The image exposes a volume at /bitnami/postgresql for the PostgreSQL data and configurations. For persistence you can mount a directory at this location from your host. If the mounted directory is empty, it will be initialized on the first run. bash docker run -v /path/to/postgresql-persistence:/bitnami/postgresql bitnami/postgresql:latest or using Docker Compose: yaml version: '2' services: postgresql: image: 'bitnami/postgresql:latest' ports: - '5432:5432' volumes: - /path/to/postgresql-persistence:/bitnami/postgresql # Connecting to other containers Using Docker container networking, a PostgreSQL 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 PostgreSQL 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 bash $ docker network create app-tier --driver bridge ### Step 2: Launch the PostgreSQL server instance Use the --network app-tier argument to the docker run command to attach the PostgreSQL container to the app-tier network. bash $ docker run -d --name postgresql-server \ --network app-tier \ bitnami/postgresql:latest ### Step 3: Launch your PostgreSQL client instance Finally we create a new container instance to launch the PostgreSQL client and connect to the server created in the previous step: bash $ docker run -it --rm \ --network app-tier \ bitnami/postgresql:latest psql -h postgresql-server -U postgres ## Using Docker Compose 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 PostgreSQL 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: postgresql: image: 'bitnami/postgresql: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 postgresql to connect to the PostgreSQL server Launch the containers using: bash $ docker-compose up -d # Configuration ## Setting the root password on first run In the above commands you may have noticed the use of the POSTGRESQL_PASSWORD environment variable. Passing the POSTGRESQL_PASSWORD environment variable when running the image for the first time will set the password of the postgres user to the value of POSTGRESQL_PASSWORD. bash docker run --name postgresql -e POSTGRESQL_PASSWORD=password123 bitnami/postgresql:latest or using Docker Compose: yaml version: '2' services: postgresql: image: 'bitnami/postgresql:latest' ports: - '5432:5432' environment: - POSTGRESQL_PASSWORD=password123 Note! The postgres user is a superuser and has full administrative access to the PostgreSQL database. ## Creating a database on first run By passing the POSTGRESQL_DATABASE environment variable when running the image for the first time, a database will be created. This is useful if your application requires that a database already exists, saving you from having to manually create the database using the PostgreSQL client. bash docker run --name postgresql -e POSTGRESQL_DATABASE=my_database bitnami/postgresql:latest or using Docker Compose: yaml version: '2' services: postgresql: image: 'bitnami/postgresql:latest' ports: - '5432:5432' environment: - POSTGRESQL_DATABASE=my_database ## Creating a database user on first run You can also create a restricted database user that only has permissions for the database created with the POSTGRESQL_DATABASE environment variable. To do this, provide the POSTGRESQL_USERNAME environment variable. bash docker run --name postgresql -e POSTGRESQL_USERNAME=my_user -e POSTGRESQL_PASSWORD=password123 -e POSTGRESQL_DATABASE=my_database bitnami/postgresql:latest or using Docker Compose: yaml version: '2' services: postgresql: image: 'bitnami/postgresql:latest' ports: - '5432:5432' environment: - POSTGRESQL_USERNAME=my_user - POSTGRESQL_PASSWORD=password123 - POSTGRESQL_DATABASE=my_database Note! When POSTGRESQL_USERNAME is specified, the postgres user is not assigned a password and as a result you cannot login remotely to the PostgreSQL server as the postgres user. ## Setting up a streaming replication A Streaming replication cluster can easily be setup with the Bitnami PostgreSQL Docker Image using the following environment variables: - POSTGRESQL_REPLICATION_MODE: Replication mode. Possible values master/slave. No defaults. - POSTGRESQL_REPLICATION_USER: The replication user created on the master on first run. No defaults. - POSTGRESQL_REPLICATION_PASSWORD: The replication users password. No defaults. - POSTGRESQL_MASTER_HOST: Hostname/IP of replication master (slave parameter). No defaults. - POSTGRESQL_MASTER_PORT_NUMBER: Server port of the replication master (slave parameter). Defaults to 5432. In a replication cluster you can have one master and zero or more slaves. When replication is enabled the master node is in read-write mode, while the slaves are in read-only mode. For best performance its advisable to limit the reads to the slaves. ### Step 1: Create the replication master The first step is to start the master. bash docker run --name postgresql-master \ -e POSTGRESQL_REPLICATION_MODE=master \ -e POSTGRESQL_USERNAME=my_user \ -e POSTGRESQL_PASSWORD=password123 \ -e POSTGRESQL_DATABASE=my_database \ -e POSTGRESQL_REPLICATION_USER=my_repl_user \ -e POSTGRESQL_REPLICATION_PASSWORD=my_repl_password \ bitnami/postgresql:latest In this command we are configuring the container as the master using the POSTGRESQL_REPLICATION_MODE=master parameter. A replication user is specified using the POSTGRESQL_REPLICATION_USER and POSTGRESQL_REPLICATION_PASSWORD parameters. ### Step 2: Create the replication slave Next we start a replication slave container. bash docker run --name postgresql-slave \ --link postgresql-master:master \ -e POSTGRESQL_REPLICATION_MODE=slave \ -e POSTGRESQL_MASTER_HOST=master \ -e POSTGRESQL_MASTER_PORT_NUMBER=5432 \ -e POSTGRESQL_REPLICATION_USER=my_repl_user \ -e POSTGRESQL_REPLICATION_PASSWORD=my_repl_password \ bitnami/postgresql:latest In the above command the container is configured as a slave using the POSTGRESQL_REPLICATION_MODE parameter. Before the replication slave is started, the POSTGRESQL_MASTER_HOST and POSTGRESQL_MASTER_PORT_NUMBER parameters are used by the slave container to connect to the master and replicate the initial database from the master. The POSTGRESQL_REPLICATION_USER and POSTGRESQL_REPLICATION_PASSWORD credentials are used to authenticate with the master. With these two commands you now have a two node PostgreSQL master-slave streaming replication cluster up and running. You can scale the cluster by adding/removing slaves without incurring any downtime. > Note: The cluster replicates the master in its entirety, which includes all users and databases. If the master goes down you can reconfigure a slave to act as the master and begin accepting writes by creating the trigger file /tmp/postgresql.trigger.5432. For example the following command reconfigures postgresql-slave to act as the master: bash docker exec postgresql-slave touch /tmp/postgresql.trigger.5432 > Note: The configuration of the other slaves in the cluster needs to be updated so that they are aware of the new master. This would require you to restart the other slaves with --link postgresql-slave:master as per our examples. With Docker Compose the master-slave replication can be setup using: yaml version: '2' services: postgresql-master: image: 'bitnami/postgresql:latest' ports: - '5432' volumes: - 'postgresql_master_data:/bitnami/postgresql' environment: - POSTGRESQL_REPLICATION_MODE=master - POSTGRESQL_REPLICATION_USER=repl_user - POSTGRESQL_REPLICATION_PASSWORD=repl_password - POSTGRESQL_USERNAME=my_user - POSTGRESQL_PASSWORD=my_password - POSTGRESQL_DATABASE=my_database volumes: - '/path/to/postgresql-persistence:/bitnami/postgresql' postgresql-slave: image: 'bitnami/postgresql:latest' ports: - '5432' depends_on: - postgresql-master environment: - POSTGRESQL_REPLICATION_MODE=slave - POSTGRESQL_REPLICATION_USER=repl_user - POSTGRESQL_REPLICATION_PASSWORD=repl_password - POSTGRESQL_MASTER_HOST=postgresql-master - POSTGRESQL_MASTER_PORT_NUMBER=5432 Scale the number of slaves using: bash docker-compose scale postgresql-master=1 postgresql-slave=3 The above command scales up the number of slaves to 3. You can scale down in the same way. > Note: You should not scale up/down the number of master nodes. Always have only one master node running. ## Configuration file The image looks for configuration in the conf/ directory of /bitnami/postgresql. As as mentioned in Persisting your database you can mount a volume at this location and copy your own configurations in the conf/ directory. The default configuration will be copied to the conf/ directory if it's empty. ### Step 1: Run the PostgreSQL image Run the PostgreSQL image, mounting a directory from your host. bash docker run --name postgresql -v /path/to/postgresql-persistence:/bitnami/postgresql bitnami/postgresql:latest or using Docker Compose: yaml version: '2' services: postgresql: image: 'bitnami/postgresql:latest' ports: - '5432:5432' volumes: - /path/to/postgresql-persistence:/bitnami/postgresql ### Step 2: Edit the configuration Edit the configuration on your host using your favorite editor. bash vi /path/to/postgresql-persistence/conf/postgresql.conf ### Step 3: Restart PostgreSQL After changing the configuration, restart your PostgreSQL container for changes to take effect. bash docker restart postgresql or using Docker Compose: bash docker-compose restart postgresql Further Reading: - Server Configuration # Logging The Bitnami PostgreSQL Docker Image supports two different logging modes: logging to stdout, and logging to a file. ## Logging to stdout The default behavior is to log to stdout, as Docker expects. These will be collected by Docker, converted to JSON and stored in the host, to be accessible via the docker logs command. bash docker logs postgresql or using Docker Compose: bash docker-compose logs postgresql This method of logging has the downside of not being easy to manage. Without an easy way to rotate logs, they could grow exponentially and take up large amounts of disk space on your host. # Logging The Bitnami PostgreSQL Docker image sends the container logs to the stdout. To view the logs: bash docker logs postgresql or using Docker Compose: bash docker-compose logs postgresql You can configure the containers logging driver 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 bash docker stop postgresql or using Docker Compose: bash docker-compose stop postgresql ### 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. bash docker run --rm \ -v /path/to/postgresql-backups:/backups \ --volumes-from postgresql busybox \ cp -a /bitnami/postgresql:latest /backups/latest or using Docker Compose: bash docker run --rm \ -v /path/to/postgresql-backups:/backups \ --volumes-from `docker-compose ps -q postgresql` busybox \ cp -a /bitnami/postgresql:latest /backups/latest ## Restoring a backup Restoring a backup is as simple as mounting the backup as volumes in the container. bash docker run \ -v /path/to/postgresql-backups/latest:/bitnami/postgresql \ bitnami/postgresql:latest or using Docker Compose: yaml version: '2' services: postgresql: image: 'bitnami/postgresql:latest' ports: - '5432:5432' volumes: - /path/to/postgresql-backups/latest:/bitnami/postgresql ## Upgrade this image Bitnami provides up-to-date versions of PostgreSQL, 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 bash docker pull bitnami/postgresql:latest or if you're using Docker Compose, update the value of the image property to bitnami/postgresql: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. ### Step 3: Remove the currently running container bash docker rm -v postgresql or using Docker Compose: bash docker-compose rm -v postgresql ### Step 4: Run the new image Re-create your container from the new image, restoring your backup if necessary. bash docker run --name postgresql bitnami/postgresql:latest or using Docker Compose: bash docker-compose start postgresql # Testing This image is tested for expected runtime behavior, using the BATS testing framework. You can run the tests on your machine using the bats command. bash bats test.sh # Notable Changes ## 9.5.3-r5 - The POSTGRES_ prefix on environment variables is now replaced by POSTGRESQL_ - POSTGRES_USER parameter has been renamed to POSTGRESQL_USERNAME. - POSTGRES_DB parameter has been renamed to POSTGRESQL_DATABASE. - POSTGRES_MODE parameter has been renamed to POSTGRESQL_REPLICATION_MODE. ## 9.5.3-r0 - All volumes have been merged at /bitnami/postgresql. Now you only need to mount a single volume at /bitnami/postgresql for persistence. - The logs are always sent to the stdout and are no longer collected in the volume. # Contributing We'd love for you to contribute to this container. You can request new features by creating an issue, or submit a pull request with your contribution. # Issues If you encountered a problem running this container, you can file an issue. 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 (echo $BITNAMI_IMAGE_VERSION inside the container) - The command you used to run the container, and any relevant output you saw (masking any sensitive information) # Community Most real time communication happens in the #containers channel at bitnami-oss.slack.com; you can sign up at slack.oss.bitnami.com. Discussions are archived at bitnami-oss.slackarchive.io. # License Copyright (c) 2015-2016 Bitnami 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. quay.io/prometheus/busybox-linux-amd64 Busybox Linux amd64 quay.io/gauravkumar9130/busybox quay.io/rehman0288/busybox quay.io/rh-test.me/busybox quay.io/56401deb-7290-4d8b-8731-baf6d8b5d27d/mongodb Official build of Bitnami MongoDB. View README for details. # What is MongoDB? > MongoDB is a cross-platform document-oriented database. Classified as a NoSQL database, MongoDB eschews the traditional table-based relational database structure in favor of JSON-like documents with dynamic schemas, making the integration of data in certain types of applications easier and faster. # TL;DR; bash docker run --name mongodb bitnami/mongodb:latest ## Docker Compose yaml version: '2' services: mongodb: image: 'bitnami/mongodb:latest' ports: - "27017:27017" ## Kubernetes > WARNING: This is a beta configuration, currently unsupported. Get the raw URL pointing to the kubernetes.yml manifest and use kubectl to create the resources on your Kubernetes cluster like so: bash $ kubectl create -f https://raw.githubusercontent.com/bitnami/bitnami-docker-mongodb/master/kubernetes.yml # 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. * Bitnami images are built on CircleCI and automatically pushed to the Docker Hub. * All our images are based on minideb a minimalist Debian based container image which gives you a small base container image and the familiarity of a leading linux distribution. # Get this image The recommended way to get the Bitnami MongoDB Docker Image is to pull the prebuilt image from the Docker Hub Registry. bash docker pull bitnami/mongodb:latest To use a specific version, you can pull a versioned tag. You can view the list of available versions in the Docker Hub Registry. bash docker pull bitnami/mongodb:[TAG] If you wish, you can also build the image yourself. bash docker build -t bitnami/mongodb:latest https://github.com/bitnami/bitnami-docker-mongodb.git # Persisting your database 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. Note! If you have already started using your database, follow the steps on backing up and restoring to pull the data from your running container down to your host. The image exposes a volume at /bitnami/mongodb for the MongoDB data and configurations. For persistence you can mount a directory at this location from your host. If the mounted directory is empty, it will be initialized on the first run. bash docker run -v /path/to/mongodb-persistence:/bitnami/mongodb bitnami/mongodb:latest or using Docker Compose: yaml version: '2' services: mongodb: image: 'bitnami/mongodb:latest' ports: - "27017:27017" volumes: - /path/to/mongodb-persistence:/bitnami/mongodb # Connecting to other containers Using Docker container networking, a MongoDB 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 MongoDB 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 bash $ docker network create app-tier --driver bridge ### Step 2: Launch the MongoDB server instance Use the --network app-tier argument to the docker run command to attach the MongoDB container to the app-tier network. bash $ docker run -d --name mongodb-server \ --network app-tier \ bitnami/mongodb:latest ### Step 3: Launch your MongoDB client instance Finally we create a new container instance to launch the MongoDB client and connect to the server created in the previous step: bash $ docker run -it --rm \ --network app-tier \ bitnami/mongodb:latest mongo --host mongodb-server ## Using Docker Compose 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 MongoDB 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: mongodb: image: 'bitnami/mongodb: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 mongodb to connect to the MongoDB server Launch the containers using: bash $ docker-compose up -d # Configuration ## Setting the root password on first run Passing the MONGODB_ROOT_PASSWORD environment variable when running the image for the first time will set the password of the root user to the value of MONGODB_ROOT_PASSWORD and enabled authentication on the MongoDB server. bash docker run --name mongodb \ -e MONGODB_ROOT_PASSWORD=password123 bitnami/mongodb:latest or using Docker Compose: yaml version: '2' services: mongodb: image: 'bitnami/mongodb:latest' ports: - "27017:27017" environment: - MONGODB_ROOT_PASSWORD=password123 The root user is configured to have full administrative access to the MongoDB server. When MONGODB_ROOT_PASSWORD is not specified the server allows unauthenticated and unrestricted access. ## Creating a user and database on first run You can create a user with restricted access to a database while starting the container for the first time. To do this, provide the MONGODB_USERNAME, MONGO_PASSWORD and MONGODB_DATABASE environment variables. bash docker run --name mongodb \ -e MONGODB_USERNAME=my_user -e MONGODB_PASSWORD=password123 \ -e MONGODB_DATABASE=my_database bitnami/mongodb:latest or using Docker Compose: yaml version: '2' services: mongodb: image: 'bitnami/mongodb:latest' ports: - "27017:27017" environment: - MONGODB_USERNAME=my_user - MONGODB_PASSWORD=password123 - MONGODB_DATABASE=my_database Note! Creation of a user enables authentication on the MongoDB server and as a result unauthenticated access by any user is not permitted. ## Setting up a replication A replication cluster can easily be setup with the Bitnami MongoDB Docker Image using the following environment variables: - MONGODB_REPLICA_SET_MODE: The replication mode. Possible values primary/secondary/arbiter. No defaults. - MONGODB_REPLICA_SET_NAME: MongoDB replica set name. Default: replicaset - MONGODB_PRIMARY_HOST: MongoDB primary host. No defaults. - MONGODB_PRIMARY_PORT_NUMBER: MongoDB primary port. Default: 27017 Only for authentication: - MONGODB_REPLICA_SET_KEY: MongoDB replica set key. Length should be greater than 5 characters and should not contain any special characters. Required for all nodes. No default. - MONGODB_ROOT_PASSWORD: MongoDB root password. No defaults. Only for primary node. - MONGODB_PRIMARY_ROOT_PASSWORD: MongoDB primary root password. No defaults. Only for secondaries and aribters nodes. In a replication cluster you can have one primary node, zero or more secondary nodes and zero or one arbiter node. > Note: The total number of nodes on a replica set sceneraio cannot be higher than 8 (1 primary, 6 secondaries and 1 arbiter) ### Step 1: Create the replication primary The first step is to start the MongoDB primary. bash docker run --name mongodb-primary \ -e MONGODB_REPLICA_SET_MODE=primary \ bitnami/mongodb:latest In the above command the container is configured as the primary using the MONGODB_REPLICA_SET_MODE parameter. ### Step 2: Create the replication secondary node Next we start a MongoDB secondary container. bash docker run --name mongodb-secondary \ --link mongodb-primary:primary \ -e MONGODB_REPLICA_SET_MODE=secondary \ -e MONGODB_PRIMARY_HOST=primary \ -e MONGODB_PRIMARY_PORT_NUMBER=27017 \ bitnami/mongodb:latest In the above command the container is configured as a secondary using the MONGODB_REPLICA_SET_MODE parameter. The MONGODB_PRIMARY_HOST and MONGODB_PRIMARY_PORT_NUMBER parameters are used connect and with the MongoDB primary. ### Step 3: Create a replication arbiter node Finally we start a MongoDB arbiter container. bash docker run --name mongodb-arbiter \ --link mongodb-primary:primary \ -e MONGODB_REPLICA_SET_MODE=arbiter \ -e MONGODB_PRIMARY_HOST=primary \ -e MONGODB_PRIMARY_PORT_NUMBER=27017 \ bitnami/mongodb:latest In the above command the container is configured as a arbiter using the MONGODB_REPLICA_SET_MODE parameter. The MONGODB_PRIMARY_HOST and MONGODB_PRIMARY_PORT_NUMBER parameters are used connect and with the MongoDB primary. You now have a three node MongoDB replication cluster up and running which can be scaled by adding/removing secondarys. With Docker Compose the primary/secondary/arbiter replication can be setup using: yaml version: '2' services: mongodb-primary: image: 'bitnami/mongodb:latest' environment: - MONGODB_REPLICA_SET_MODE=primary volumes: - 'mongodb_master_data:/bitnami/mongodb' mongodb-secondary: image: 'bitnami/mongodb:latest' depends_on: - mongodb-primary environment: - MONGODB_REPLICA_SET_MODE=secondary - MONGODB_PRIMARY_HOST=mongodb-primary - MONGODB_PRIMARY_PORT_NUMBER=27017 mongodb-arbiter: image: 'bitnami/mongodb:latest' depends_on: - mongodb-primary environment: - MONGODB_REPLICA_SET_MODE=arbiter - MONGODB_PRIMARY_HOST=mongodb-primary - MONGODB_PRIMARY_PORT_NUMBER=27017 volumes: mongodb_master_data: driver: local Or in case you want to set up the replica set with authentication you can use the following file: yaml version: '2' services: mongodb-primary: image: 'bitnami/mongodb:latest' environment: - MONGODB_REPLICA_SET_MODE=primary - MONGODB_ROOT_PASSWORD=password123 - MONGODB_REPLICA_SET_KEY=replicasetkey123 volumes: - 'mongodb_master_data:/bitnami/mongodb' mongodb-secondary: image: 'bitnami/mongodb:latest' depends_on: - mongodb-primary environment: - MONGODB_REPLICA_SET_MODE=secondary - MONGODB_PRIMARY_HOST=mongodb-primary - MONGODB_PRIMARY_PORT_NUMBER=27017 - MONGODB_PRIMARY_ROOT_PASSWORD=password123 - MONGODB_REPLICA_SET_KEY=replicasetkey123 mongodb-arbiter: image: 'bitnami/mongodb:latest' depends_on: - mongodb-primary environment: - MONGODB_REPLICA_SET_MODE=arbiter - MONGODB_PRIMARY_HOST=mongodb-primary - MONGODB_PRIMARY_PORT_NUMBER=27017 - MONGODB_PRIMARY_ROOT_PASSWORD=password123 - MONGODB_REPLICA_SET_KEY=replicasetkey123 volumes: mongodb_master_data: driver: local Scale the number of secondary nodes using: bash docker-compose scale mongodb-primary=1 mongodb-secondary=3 mongodb-arbiter=1 The above command scales up the number of secondary nodes to 3. You can scale down in the same way. > Note: You should not scale up/down the number of primary nodes. Always have only one primary node running. ## Configuration file The image looks for configuration in the conf/ directory of /bitnami/mongodb. As as mentioned in Persisting your database you can mount a volume at this location and copy your own configurations in the conf/ directory. The default configuration will be copied to the conf/ directory if it's empty. ### Step 1: Run the MongoDB image Run the MongoDB image, mounting a directory from your host. bash docker run --name mongodb -v /path/to/mongodb-persistence:/bitnami/mongodb bitnami/mongodb:latest or using Docker Compose: yaml version: '2' services: mongodb: image: 'bitnami/mongodb:latest' ports: - "27017:27017" volumes: - /path/to/mongodb-persistence:/bitnami/mongodb ### Step 2: Edit the configuration Edit the configuration on your host using your favorite editor. bash vi /path/to/mongodb-persistence/conf/mongodb.conf ### Step 3: Restart MongoDB After changing the configuration, restart your MongoDB container for changes to take effect. bash docker restart mongodb or using Docker Compose: bash docker-compose restart mongodb Further Reading: - Configuration File Options # Logging The Bitnami MongoDB Docker image sends the container logs to the stdout. To view the logs: bash docker logs mongodb or using Docker Compose: bash docker-compose logs mongodb You can configure the containers logging driver 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 bash docker stop mongodb or using Docker Compose: bash docker-compose stop mongodb ### 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. bash docker run --rm \ -v /path/to/mongodb-backups:/backups \ --volumes-from mongodb busybox \ cp -a /bitnami/mongodb:latest /backups/latest or using Docker Compose: bash docker run --rm \ -v /path/to/mongodb-backups:/backups \ --volumes-from `docker-compose ps -q mongodb` busybox \ cp -a /bitnami/mongodb:latest /backups/latest ## Restoring a backup Restoring a backup is as simple as mounting the backup as volumes in the container. bash docker run \ -v /path/to/mongodb-backups/latest:/bitnami/mongodb bitnami/mongodb:latest or using Docker Compose: yaml version: '2' services: mongodb: image: 'bitnami/mongodb:latest' ports: - "27017:27017" volumes: - /path/to/mongodb-backups/latest:/bitnami/mongodb ## Upgrade this image Bitnami provides up-to-date versions of MongoDB, 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 bash docker pull bitnami/mongodb:latest or if you're using Docker Compose, update the value of the image property to bitnami/mongodb: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. ### Step 3: Remove the currently running container bash docker rm -v mongodb or using Docker Compose: bash docker-compose rm -v mongodb ### Step 4: Run the new image Re-create your container from the new image, restoring your backup if necessary. bash docker run --name mongodb bitnami/mongodb:latest or using Docker Compose: bash docker-compose start mongodb # Notable Changes ## 3.2.7-r5 - MONGODB_USER parameter has been renamed to MONGODB_USERNAME. ## 3.2.6-r0 - All volumes have been merged at /bitnami/mongodb. Now you only need to mount a single volume at /bitnami/mongodb for persistence. - The logs are always sent to the stdout and are no longer collected in the volume. # Contributing We'd love for you to contribute to this container. You can request new features by creating an issue, or submit a pull request with your contribution. # Issues If you encountered a problem running this container, you can file an issue. 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 (echo $BITNAMI_IMAGE_VERSION inside the container) - The command you used to run the container, and any relevant output you saw (masking any sensitive information) # Community Most real time communication happens in the #containers channel at bitnami-oss.slack.com; you can sign up at slack.oss.bitnami.com. Discussions are archived at bitnami-oss.slackarchive.io. # License Copyright (c) 2015-2016 Bitnami 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. quay.io/56401deb-7290-4d8b-8731-baf6d8b5d27d/redis Official build of Bitnami Redis. View README for details. # What is Redis? > Redis is an advanced key-value cache and store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets, sorted sets, bitmaps and hyperloglogs. redis.io # TL;DR; bash docker run --name redis bitnami/redis:latest ## Docker Compose yaml version: '2' services: redis: image: 'bitnami/redis:latest' ports: - '6379:6379' ## Kubernetes > WARNING: This is a beta configuration, currently unsupported. Get the raw URL pointing to the kubernetes.yml manifest and use kubectl to create the resources on your Kubernetes cluster like so: bash $ kubectl create -f https://raw.githubusercontent.com/bitnami/bitnami-docker-redis/master/kubernetes.yml # 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. * Bitnami images are built on CircleCI and automatically pushed to the Docker Hub. * All our images are based on minideb a minimalist Debian based container image which gives you a small base container image and the familiarity of a leading linux distribution. # Get this image The recommended way to get the Bitnami Redis Docker Image is to pull the prebuilt image from the Docker Hub Registry. bash docker pull bitnami/redis:latest To use a specific version, you can pull a versioned tag. You can view the list of available versions in the Docker Hub Registry. bash docker pull bitnami/redis:[TAG] If you wish, you can also build the image yourself. bash docker build -t bitnami/redis:latest https://github.com/bitnami/bitnami-docker-redis.git # Persisting your database If you remove the container all your data and configurations will be lost, and the next time you run the image the data and configurations will be reinitialized. To avoid this loss of data, you should mount a volume that will persist even after the container is removed. Note! If you have already started using your database, follow the steps on backing up and restoring to pull the data from your running container down to your host. The image exposes a volume at /bitnami/redis for the Redis data and configurations. For persistence you can mount a directory at this location from your host. If the mounted directory is empty, it will be initialized on the first run. bash docker run -v /path/to/redis-persistence:/bitnami/redis bitnami/redis:latest or using Docker Compose: yaml version: '2' services: redis: image: 'bitnami/redis:latest' ports: - '6379:6379' volumes: - /path/to/redis-persistence:/bitnami/redis # Connecting to other containers Using Docker container networking, a Redis 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 Redis 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 bash $ docker network create app-tier --driver bridge ### Step 2: Launch the Redis server instance Use the --network app-tier argument to the docker run command to attach the Redis container to the app-tier network. bash $ docker run -d --name redis-server \ --network app-tier \ bitnami/redis:latest ### Step 3: Launch your Redis client instance Finally we create a new container instance to launch the Redis client and connect to the server created in the previous step: bash $ docker run -it --rm \ --network app-tier \ bitnami/redis:latest redis-cli -h redis-server ## Using Docker Compose 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 Redis 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: redis: image: 'bitnami/redis: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 redis to connect to the Redis server Launch the containers using: bash $ docker-compose up -d # Configuration ## Setting the server password on first run Passing the REDIS_PASSWORD environment variable when running the image for the first time will set the Redis server password to the value of REDIS_PASSWORD. bash docker run --name redis -e REDIS_PASSWORD=password123 bitnami/redis:latest or using Docker Compose: yaml version: '2' services: redis: image: 'bitnami/redis:latest' ports: - '6379:6379' environment: - REDIS_PASSWORD=password123 ## Setting up a replication A replication cluster can easily be setup with the Bitnami Redis Docker Image using the following environment variables: - REDIS_REPLICATION_MODE: The replication mode. Possible values master/slave. No defaults. - REDIS_MASTER_HOST: Hostname/IP of replication master (slave parameter). No defaults. - REDIS_MASTER_PORT_NUMBER: Server port of the replication master (slave parameter). Defaults to 6379. - REDIS_MASTER_PASSWORD: Password to authenticate with the master (slave parameter). No defaults. In a replication cluster you can have one master and zero or more slaves. When replication is enabled the master node is in read-write mode, while the slaves are in read-only mode. For best performance its advisable to limit the reads to the slaves. ### Step 1: Create the replication master The first step is to start the Redis master. bash docker run --name redis-master \ -e REDIS_REPLICATION_MODE=master \ -e REDIS_PASSWORD=masterpassword123 \ bitnami/redis:latest In the above command the container is configured as the master using the REDIS_REPLICATION_MODE parameter. The REDIS_PASSWORD parameter enables authentication on the Redis master. ### Step 2: Create the replication slave Next we start a Redis slave container. bash docker run --name redis-slave \ --link redis-master:master \ -e REDIS_REPLICATION_MODE=slave \ -e REDIS_MASTER_HOST=master \ -e REDIS_MASTER_PORT_NUMBER=6379 \ -e REDIS_MASTER_PASSWORD=masterpassword123 \ -e REDIS_PASSWORD=password123 \ bitnami/redis:latest In the above command the container is configured as a slave using the REDIS_REPLICATION_MODE parameter. The REDIS_MASTER_HOST, REDIS_MASTER_PORT_NUMBER and REDIS_MASTER_PASSWORD parameters are used connect and authenticate with the Redis master. The REDIS_PASSWORD parameter enables authentication on the Redis slave. You now have a two node Redis master/slave replication cluster up and running which can be scaled by adding/removing slaves. If the Redis master goes down you can reconfigure a slave to become a master using: bash docker exec redis-slave redis-cli -a password123 SLAVEOF NO ONE > Note: The configuration of the other slaves in the cluster needs to be updated so that they are aware of the new master. In our example, this would involve restarting the other slaves with --link redis-slave:master. With Docker Compose the master/slave replication can be setup using: yaml version: '2' services: redis-primary: image: 'bitnami/redis:latest' ports: - '6379' environment: - REDIS_REPLICATION_MODE=master - REDIS_PASSWORD=my_password volumes: - '/path/to/redis-persistence:/bitnami/redis' redis-secondary: image: 'bitnami/redis:latest' ports: - '6379' depends_on: - redis-primary environment: - REDIS_REPLICATION_MODE=slave - REDIS_MASTER_HOST=redis-primary - REDIS_MASTER_PORT_NUMBER=6379 - REDIS_MASTER_PASSWORD=my_password - REDIS_PASSWORD=my_password Scale the number of slaves using: bash docker-compose scale redis-primary=1 redis-secondary=3 The above command scales up the number of slaves to 3. You can scale down in the same way. > Note: You should not scale up/down the number of master nodes. Always have only one master node running. ## Configuration file The image looks for configuration in the conf/ directory of /bitnami/redis. As as mentioned in Persisting your database you can mount a volume at this location and copy your own configurations in the conf/ directory. The default configuration will be copied to the conf/ directory if it's empty. ### Step 1: Run the Redis image Run the Redis image, mounting a directory from your host. bash docker run --name redis -v /path/to/redis-persistence:/bitnami/redis bitnami/redis:latest or using Docker Compose: yaml version: '2' services: redis: image: 'bitnami/redis:latest' ports: - '6379:6379' volumes: - /path/to/redis-persistence:/bitnami/redis ### Step 2: Edit the configuration Edit the configuration on your host using your favorite editor. bash vi /path/to/redis-persistence/conf/redis.conf ### Step 3: Restart Redis After changing the configuration, restart your Redis container for changes to take effect. bash docker restart redis or using Docker Compose: bash docker-compose restart redis Further Reading: - Redis Configuration Documentation # Logging The Bitnami Redis Docker image sends the container logs to the stdout. To view the logs: bash docker logs redis or using Docker Compose: bash docker-compose logs redis You can configure the containers logging driver 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 bash docker stop redis or using Docker Compose: bash docker-compose stop redis ### 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. bash docker run --rm -v /path/to/redis-backups:/backups --volumes-from redis busybox \ cp -a /bitnami/redis:latest /backups/latest or using Docker Compose: bash docker run --rm -v /path/to/redis-backups:/backups --volumes-from `docker-compose ps -q redis` busybox \ cp -a /bitnami/redis:latest /backups/latest ## Restoring a backup Restoring a backup is as simple as mounting the backup as volumes in the container. bash docker run -v /path/to/redis-backups/latest:/bitnami/redis bitnami/redis:latest or using Docker Compose: yaml version: '2' services: redis: image: 'bitnami/redis:latest' ports: - '6379:6379' volumes: - /path/to/redis-backups/latest:/bitnami/redis ## Upgrade this image Bitnami provides up-to-date versions of Redis, 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 bash docker pull bitnami/redis:latest or if you're using Docker Compose, update the value of the image property to bitnami/redis: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. ### Step 3: Remove the currently running container bash docker rm -v redis or using Docker Compose: bash docker-compose rm -v redis ### Step 4: Run the new image Re-create your container from the new image, restoring your backup if necessary. bash docker run --name redis bitnami/redis:latest or using Docker Compose: bash docker-compose start redis # Notable Changes ## 3.2.0-r0 - All volumes have been merged at /bitnami/redis. Now you only need to mount a single volume at /bitnami/redis for persistence. - The logs are always sent to the stdout and are no longer collected in the volume. # Contributing We'd love for you to contribute to this container. You can request new features by creating an issue, or submit a pull request with your contribution. # Issues If you encountered a problem running this container, you can file an issue. 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 (echo $BITNAMI_IMAGE_VERSION inside the container) - The command you used to run the container, and any relevant output you saw (masking any sensitive information) # Community Most real time communication happens in the #containers channel at bitnami-oss.slack.com; you can sign up at slack.oss.bitnami.com. Discussions are archived at bitnami-oss.slackarchive.io. # License Copyright (c) 2015-2016 Bitnami Licensed under the Apache License, Version 2.0 (the "License"); you
..[more]

Describe the results you expected:
INDEX NAME DESCRIPTION STARS OFFICIAL AUTOMATED
docker.io docker.io/library/busybox Busybox base image. 1882 [OK]
docker.io docker.io/radial/busyboxplus Full-chain, Internet enabled, busybox made f... 30 [OK]
docker.io docker.io/yauritux/busybox-curl Busybox with CURL 8
...

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

No

Additional environment details (AWS, VirtualBox, physical, etc.):

---

[Luap99]

You have to use podman search busybox --no-trunc=false.

@containers/podman-maintainers Why is no --no-trunc default for search, this does not match other commands? As you can see in the issue description this will clutter the output when a image has a long description.

[vrothberg]

Happened when fixing #11894. Not sure why though.

[vrothberg]

Looking at the code, I don't see any reason why Podman should default to true.

[vrothberg]

Opened #14047.