Run update.sh
This commit is contained in:
parent
de9ded099e
commit
fb12582b40
|
|
@ -198,12 +198,6 @@ The Docker documentation is a good starting point for understanding the differen
|
|||
|
||||
The `-v /my/own/datadir:/opt/bonita` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/opt/bonita` inside the container, where Bonita will deploy the bundle and write data files by default.
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to the new data directory so that the container will be allowed to access it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/own/datadir
|
||||
```
|
||||
|
||||
## Migrate from an earlier version of Bonita
|
||||
|
||||
- Stop the container to perform a backup
|
||||
|
|
|
|||
|
|
@ -203,12 +203,6 @@ The Docker documentation is a good starting point for understanding the differen
|
|||
|
||||
The `-v /my/own/datadir:/var/lib/cassandra` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/var/lib/cassandra` inside the container, where Cassandra by default will write its data files.
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to the new data directory so that the container will be allowed to access it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/own/datadir
|
||||
```
|
||||
|
||||
## No connections until Cassandra init completes
|
||||
|
||||
If there is no database initialized when the container starts, then a default database will be created. While this is the expected behavior, this means that it will not accept incoming connections until such initialization completes. This may cause issues when using automation tools, such as `docker-compose`, which start several containers simultaneously.
|
||||
|
|
|
|||
|
|
@ -118,6 +118,16 @@ Alternatively you can use a [data container](http://docs.docker.com/engine/tutor
|
|||
$ docker run -d --name some-ghost --volumes-from some-ghost-data ghost
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
All Ghost configuration parameters (such as `url`) can be specified via environment variables. See [the Ghost documentation](https://docs.ghost.org/docs/config#section-running-ghost-with-config-env-variables) for details about what configuration is allowed and how to convert a nested configuration key into the appropriate environment variable name:
|
||||
|
||||
```console
|
||||
$ docker run -d --name some-ghost -e url=http://some-ghost.example.com ghost
|
||||
```
|
||||
|
||||
(There are further configuration examples in the `stack.yml` listed below.)
|
||||
|
||||
## What is the Node.js version?
|
||||
|
||||
When opening a ticket at https://github.com/TryGhost/Ghost/issues it becomes necessary to know the version of Node.js in use:
|
||||
|
|
|
|||
|
|
@ -153,12 +153,6 @@ $ docker run --name some-mariadb -v /my/custom:/etc/mysql/conf.d -e MYSQL_ROOT_P
|
|||
|
||||
This will start a new container `some-mariadb` where the MariaDB instance uses the combined startup settings from `/etc/mysql/my.cnf` and `/etc/mysql/conf.d/config-file.cnf`, with settings from the latter taking precedence.
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to your new config file so that the container will be allowed to mount it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/custom
|
||||
```
|
||||
|
||||
### Configuration without a `cnf` file
|
||||
|
||||
Many configuration options can be passed as flags to `mysqld`. This will give you the flexibility to customize the container without needing a `cnf` file. For example, if you want to change the default encoding and collation for all tables to use UTF-8 (`utf8mb4`) just run the following:
|
||||
|
|
@ -233,12 +227,6 @@ The Docker documentation is a good starting point for understanding the differen
|
|||
|
||||
The `-v /my/own/datadir:/var/lib/mysql` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/var/lib/mysql` inside the container, where MySQL by default will write its data files.
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to the new data directory so that the container will be allowed to access it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/own/datadir
|
||||
```
|
||||
|
||||
## No connections until MySQL init completes
|
||||
|
||||
If there is no database initialized when the container starts, then a default database will be created. While this is the expected behavior, this means that it will not accept incoming connections until such initialization completes. This may cause issues when using automation tools, such as `docker-compose`, which start several containers simultaneously.
|
||||
|
|
|
|||
|
|
@ -279,12 +279,6 @@ The `-v /my/own/datadir:/data/db` part of the command mounts the `/my/own/datadi
|
|||
|
||||
This image also defines a volume for `/data/configdb` [for use with `--configsvr` (see docs.mongodb.com for more details)](https://docs.mongodb.com/v3.4/reference/program/mongod/#cmdoption-configsvr).
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to the new data directory so that the container will be allowed to access it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/own/datadir
|
||||
```
|
||||
|
||||
## Creating database dumps
|
||||
|
||||
Most of the normal tools will work, although their usage might be a little convoluted in some cases to ensure they have access to the `mongod` server. A simple way to ensure this is to use `docker exec` and run the tool from the same container, similar to the following:
|
||||
|
|
|
|||
|
|
@ -149,12 +149,6 @@ $ docker run --name some-mysql -v /my/custom:/etc/mysql/conf.d -e MYSQL_ROOT_PAS
|
|||
|
||||
This will start a new container `some-mysql` where the MySQL instance uses the combined startup settings from `/etc/mysql/my.cnf` and `/etc/mysql/conf.d/config-file.cnf`, with settings from the latter taking precedence.
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to your new config file so that the container will be allowed to mount it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/custom
|
||||
```
|
||||
|
||||
### Configuration without a `cnf` file
|
||||
|
||||
Many configuration options can be passed as flags to `mysqld`. This will give you the flexibility to customize the container without needing a `cnf` file. For example, if you want to change the default encoding and collation for all tables to use UTF-8 (`utf8mb4`) just run the following:
|
||||
|
|
@ -235,12 +229,6 @@ The Docker documentation is a good starting point for understanding the differen
|
|||
|
||||
The `-v /my/own/datadir:/var/lib/mysql` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/var/lib/mysql` inside the container, where MySQL by default will write its data files.
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to the new data directory so that the container will be allowed to access it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/own/datadir
|
||||
```
|
||||
|
||||
## No connections until MySQL init completes
|
||||
|
||||
If there is no database initialized when the container starts, then a default database will be created. While this is the expected behavior, this means that it will not accept incoming connections until such initialization completes. This may cause issues when using automation tools, such as `docker-compose`, which start several containers simultaneously.
|
||||
|
|
|
|||
|
|
@ -16,15 +16,15 @@ WARNING:
|
|||
|
||||
# Supported tags and respective `Dockerfile` links
|
||||
|
||||
- [`12.0.11-apache`, `12.0-apache`, `12-apache`, `12.0.11`, `12.0`, `12` (*12.0/apache/Dockerfile*)](https://github.com/nextcloud/docker/blob/f6abe4472b50d5bccff4428329fced339835cf69/12.0/apache/Dockerfile)
|
||||
- [`12.0.11-fpm-alpine`, `12.0-fpm-alpine`, `12-fpm-alpine` (*12.0/fpm-alpine/Dockerfile*)](https://github.com/nextcloud/docker/blob/f6abe4472b50d5bccff4428329fced339835cf69/12.0/fpm-alpine/Dockerfile)
|
||||
- [`12.0.11-fpm`, `12.0-fpm`, `12-fpm` (*12.0/fpm/Dockerfile*)](https://github.com/nextcloud/docker/blob/f6abe4472b50d5bccff4428329fced339835cf69/12.0/fpm/Dockerfile)
|
||||
- [`13.0.6-apache`, `13.0-apache`, `13-apache`, `stable-apache`, `production-apache`, `13.0.6`, `13.0`, `13`, `stable`, `production` (*13.0/apache/Dockerfile*)](https://github.com/nextcloud/docker/blob/f6abe4472b50d5bccff4428329fced339835cf69/13.0/apache/Dockerfile)
|
||||
- [`13.0.6-fpm-alpine`, `13.0-fpm-alpine`, `13-fpm-alpine`, `stable-fpm-alpine`, `production-fpm-alpine` (*13.0/fpm-alpine/Dockerfile*)](https://github.com/nextcloud/docker/blob/f6abe4472b50d5bccff4428329fced339835cf69/13.0/fpm-alpine/Dockerfile)
|
||||
- [`13.0.6-fpm`, `13.0-fpm`, `13-fpm`, `stable-fpm`, `production-fpm` (*13.0/fpm/Dockerfile*)](https://github.com/nextcloud/docker/blob/f6abe4472b50d5bccff4428329fced339835cf69/13.0/fpm/Dockerfile)
|
||||
- [`14.0.0-apache`, `14.0-apache`, `14-apache`, `apache`, `14.0.0`, `14.0`, `14`, `latest` (*14.0/apache/Dockerfile*)](https://github.com/nextcloud/docker/blob/f6abe4472b50d5bccff4428329fced339835cf69/14.0/apache/Dockerfile)
|
||||
- [`14.0.0-fpm-alpine`, `14.0-fpm-alpine`, `14-fpm-alpine`, `fpm-alpine` (*14.0/fpm-alpine/Dockerfile*)](https://github.com/nextcloud/docker/blob/f6abe4472b50d5bccff4428329fced339835cf69/14.0/fpm-alpine/Dockerfile)
|
||||
- [`14.0.0-fpm`, `14.0-fpm`, `14-fpm`, `fpm` (*14.0/fpm/Dockerfile*)](https://github.com/nextcloud/docker/blob/f6abe4472b50d5bccff4428329fced339835cf69/14.0/fpm/Dockerfile)
|
||||
- [`12.0.11-apache`, `12.0-apache`, `12-apache`, `12.0.11`, `12.0`, `12` (*12.0/apache/Dockerfile*)](https://github.com/nextcloud/docker/blob/f5d27c615330fc4331522405fd19234e02385770/12.0/apache/Dockerfile)
|
||||
- [`12.0.11-fpm-alpine`, `12.0-fpm-alpine`, `12-fpm-alpine` (*12.0/fpm-alpine/Dockerfile*)](https://github.com/nextcloud/docker/blob/f5d27c615330fc4331522405fd19234e02385770/12.0/fpm-alpine/Dockerfile)
|
||||
- [`12.0.11-fpm`, `12.0-fpm`, `12-fpm` (*12.0/fpm/Dockerfile*)](https://github.com/nextcloud/docker/blob/f5d27c615330fc4331522405fd19234e02385770/12.0/fpm/Dockerfile)
|
||||
- [`13.0.6-apache`, `13.0-apache`, `13-apache`, `stable-apache`, `production-apache`, `13.0.6`, `13.0`, `13`, `stable`, `production` (*13.0/apache/Dockerfile*)](https://github.com/nextcloud/docker/blob/f5d27c615330fc4331522405fd19234e02385770/13.0/apache/Dockerfile)
|
||||
- [`13.0.6-fpm-alpine`, `13.0-fpm-alpine`, `13-fpm-alpine`, `stable-fpm-alpine`, `production-fpm-alpine` (*13.0/fpm-alpine/Dockerfile*)](https://github.com/nextcloud/docker/blob/f5d27c615330fc4331522405fd19234e02385770/13.0/fpm-alpine/Dockerfile)
|
||||
- [`13.0.6-fpm`, `13.0-fpm`, `13-fpm`, `stable-fpm`, `production-fpm` (*13.0/fpm/Dockerfile*)](https://github.com/nextcloud/docker/blob/f5d27c615330fc4331522405fd19234e02385770/13.0/fpm/Dockerfile)
|
||||
- [`14.0.0-apache`, `14.0-apache`, `14-apache`, `apache`, `14.0.0`, `14.0`, `14`, `latest` (*14.0/apache/Dockerfile*)](https://github.com/nextcloud/docker/blob/f5d27c615330fc4331522405fd19234e02385770/14.0/apache/Dockerfile)
|
||||
- [`14.0.0-fpm-alpine`, `14.0-fpm-alpine`, `14-fpm-alpine`, `fpm-alpine` (*14.0/fpm-alpine/Dockerfile*)](https://github.com/nextcloud/docker/blob/f5d27c615330fc4331522405fd19234e02385770/14.0/fpm-alpine/Dockerfile)
|
||||
- [`14.0.0-fpm`, `14.0-fpm`, `14-fpm`, `fpm` (*14.0/fpm/Dockerfile*)](https://github.com/nextcloud/docker/blob/f5d27c615330fc4331522405fd19234e02385770/14.0/fpm/Dockerfile)
|
||||
|
||||
# Quick reference
|
||||
|
||||
|
|
|
|||
|
|
@ -151,12 +151,6 @@ $ docker run --name some-percona -v /my/custom:/etc/mysql/conf.d -e MYSQL_ROOT_P
|
|||
|
||||
This will start a new container `some-percona` where the Percona instance uses the combined startup settings from `/etc/mysql/my.cnf` and `/etc/mysql/conf.d/config-file.cnf`, with settings from the latter taking precedence.
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to your new config file so that the container will be allowed to mount it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/custom
|
||||
```
|
||||
|
||||
### Configuration without a `cnf` file
|
||||
|
||||
Many configuration options can be passed as flags to `mysqld`. This will give you the flexibility to customize the container without needing a `cnf` file. For example, if you want to change the default encoding and collation for all tables to use UTF-8 (`utf8mb4`) just run the following:
|
||||
|
|
@ -235,12 +229,6 @@ The Docker documentation is a good starting point for understanding the differen
|
|||
|
||||
The `-v /my/own/datadir:/var/lib/mysql` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/var/lib/mysql` inside the container, where MySQL by default will write its data files.
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to the new data directory so that the container will be allowed to access it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/own/datadir
|
||||
```
|
||||
|
||||
## No connections until MySQL init completes
|
||||
|
||||
If there is no database initialized when the container starts, then a default database will be created. While this is the expected behavior, this means that it will not accept incoming connections until such initialization completes. This may cause issues when using automation tools, such as `docker-compose`, which start several containers simultaneously.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ WARNING:
|
|||
|
||||
# Supported tags and respective `Dockerfile` links
|
||||
|
||||
- [`2.0`, `2.0-20180823`, `latest` (*docker/Dockerfile*)](https://github.com/vmware/photon-docker-image/blob/3c1e91142077d224ce57f8890e3ae12f64a92981/docker/Dockerfile)
|
||||
- [`2.0`, `2.0-20180912`, `latest` (*docker/Dockerfile*)](https://github.com/vmware/photon-docker-image/blob/fc87dfc87108182fa5469929acfbbeda407a753c/docker/Dockerfile)
|
||||
- [`1.0`, `1.0-20180816` (*docker/Dockerfile*)](https://github.com/vmware/photon-docker-image/blob/fda590b062d1ac4d575c67fff4847b483f5097cd/docker/Dockerfile)
|
||||
- [`dev`, `dev-20180904` (*docker/Dockerfile*)](https://github.com/vmware/photon-docker-image/blob/ef64980d07a68bd0cd97de9224df5c3e62e4db12/docker/Dockerfile)
|
||||
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ PHP is a server-side scripting language designed for web development, but which
|
|||
|
||||

|
||||
|
||||
# How to use this image.
|
||||
# How to use this image
|
||||
|
||||
## With Command Line
|
||||
|
||||
|
|
@ -162,15 +162,7 @@ $ docker build -t my-php-app .
|
|||
$ docker run -d --name my-running-app my-php-app
|
||||
```
|
||||
|
||||
We recommend that you add a custom `php.ini` configuration. `COPY` it into `/usr/local/etc/php` by adding one more line to the Dockerfile above and running the same commands to build and run:
|
||||
|
||||
```dockerfile
|
||||
FROM php:7.2-apache
|
||||
COPY config/php.ini /usr/local/etc/php/
|
||||
COPY src/ /var/www/html/
|
||||
```
|
||||
|
||||
Where `src/` is the directory containing all your PHP code and `config/` contains your `php.ini` file.
|
||||
We recommend that you add a `php.ini` configuration file, see the "Configuration" section for details.
|
||||
|
||||
### Without a `Dockerfile`
|
||||
|
||||
|
|
@ -311,6 +303,28 @@ RUN rm /etc/apt/preferences.d/no-debian-php
|
|||
|
||||
The *proper* solution to this error is to either use `FROM debian:XXX` and install Debian's PHP packages directly, or to use `docker-php-ext-install`, `pecl`, and/or `phpize` to install the necessary additional extensions and utilities.
|
||||
|
||||
## Configuration
|
||||
|
||||
This image ships with the default [`php.ini-development`](https://github.com/php/php-src/blob/master/php.ini-development) and [`php.ini-production`](https://github.com/php/php-src/blob/master/php.ini-production) configuration files.
|
||||
|
||||
It is *strongly* recommended to use the production config for images used in production environments!
|
||||
|
||||
The default config can be customized by copying configuration files into the `$PHP_INI_DIR/conf.d/` directory.
|
||||
|
||||
### Example
|
||||
|
||||
```dockerfile
|
||||
FROM php:7.2-fpm-alpine
|
||||
|
||||
# Use the default production configuration
|
||||
RUN mv $PHP_INI_DIR/php.ini-production $PHP_INI_DIR/php.ini
|
||||
|
||||
# Override with custom opcache settings
|
||||
COPY config/opcache.ini $PHP_INI_DIR/conf.d/
|
||||
```
|
||||
|
||||
Where `config/` contains your custom configuration files.
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `php` images come in many flavors, each designed for a specific use case.
|
||||
|
|
|
|||
|
|
@ -149,12 +149,6 @@ The Docker documentation is a good starting point for understanding the differen
|
|||
|
||||
The `-v /my/own/datadir:/usr/src/redmine/files` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/usr/src/redmine/files` inside the container, where Redmine will store uploaded files.
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to the new data directory so that the container will be allowed to access it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/own/datadir
|
||||
```
|
||||
|
||||
## Port Mapping
|
||||
|
||||
If you'd like to be able to access the instance from the host without the container's IP, standard port mappings can be used. Just add `-p 3000:3000` to the `docker run` arguments and then access either `http://localhost:3000` or `http://host-ip:3000` in a browser.
|
||||
|
|
|
|||
|
|
@ -213,12 +213,6 @@ $ docker run --name some-teamspeak -v /my/own/datadir:/var/ts3server/ -d teamspe
|
|||
|
||||
The `-v /my/own/datadir:/var/ts3server/` part of the command mounts the `/my/own/datadir` directory from the underlying host system as `/var/ts3server` inside the container, where TeamSpeak by default will write its data files.
|
||||
|
||||
Note that users on host systems with SELinux enabled may see issues with this. The current workaround is to assign the relevant SELinux policy type to the new data directory so that the container will be allowed to access it:
|
||||
|
||||
```console
|
||||
$ chcon -Rt svirt_sandbox_file_t /my/own/datadir
|
||||
```
|
||||
|
||||
# License
|
||||
|
||||
View [license information](https://github.com/TeamSpeak-Systems/teamspeak-linux-docker-images/blob/master/LICENSE) for the software contained in this image.
|
||||
|
|
|
|||
Loading…
Reference in New Issue