$ docker pull registry.redhat.io/openshift3/php-55-rhel7 $ docker pull registry.redhat.io/rhscl/php-56-rhel7 $ docker pull registry.redhat.io/rhscl/php-70-rhel7
Azure Red Hat OpenShift 3.11 will be retired 30 June 2022. Support for creation of new Azure Red Hat OpenShift 3.11 clusters continues through 30 November 2020. Following retirement, remaining Azure Red Hat OpenShift 3.11 clusters will be shut down to prevent security vulnerabilities.
Follow this guide to create an Azure Red Hat OpenShift 4 cluster. If you have specific questions, please contact us
Azure Red Hat OpenShift provides S2I enabled PHP images for building and running PHP applications. The PHP S2I builder image assembles your application source with any required dependencies to create a new image containing your PHP application. This resulting image can be run either by Azure Red Hat OpenShift or by a container runtime.
These images come in two flavors, depending on your needs:
RHEL 7
CentOS 7
RHEL 7 Based Images
The RHEL 7 images are available through the Red Hat Registry:
$ docker pull registry.redhat.io/openshift3/php-55-rhel7 $ docker pull registry.redhat.io/rhscl/php-56-rhel7 $ docker pull registry.redhat.io/rhscl/php-70-rhel7
CentOS 7 Based Images
CentOS images for PHP 5.5 and 5.6 are available on Docker Hub:
$ docker pull openshift/php-55-centos7 $ docker pull openshift/php-56-centos7
To use these images, you can either access them directly from these image registries or push them into your Azure Red Hat OpenShift container image registry. Additionally, you can create an image stream that points to the image, either in your container image registry or at the external location. Your Azure Red Hat OpenShift resources can then reference the image stream.
You can find example image stream definitions for all the provided Azure Red Hat OpenShift images.
S2I produces ready-to-run images by injecting source code into a container and letting the container prepare that source code for execution. It performs the following steps:
Starts a container from the builder image.
Downloads the application source.
Streams the scripts and application sources into the builder image container.
Runs the assemble script (from the builder image).
Saves the final image.
See S2I Build Process for a detailed overview of the build process.
The PHP image supports a number of environment variables which can be set to control the configuration and behavior of the PHP runtime.
To set these environment variables as part of your image, you can place them into
a .s2i/environment file
inside your source code repository, or define them in
the environment
section of the build configuration’s sourceStrategy
definition.
You can also set environment variables to be used with an existing image when creating new applications, or by updating environment variables for existing objects such as deployment configurations.
Environment variables that control build behavior must be set as part of the s2i build configuration or in the .s2i/environment file to make them available to the build steps. |
The following environment variables set their equivalent property value in the php.ini file:
Variable Name | Description | Default |
---|---|---|
|
Informs PHP of the errors, warnings, and notices for which you would like it to take action. |
E_ALL & ~E_NOTICE |
|
Controls if and where PHP outputs errors, notices, and warnings. |
ON |
|
Causes any display errors that occur during PHP’s startup sequence to be handled separately from display errors. |
OFF |
|
Stores the last error/warning message in |
OFF |
|
Links errors to documentation that is related to the error. |
ON |
|
Path for PHP source files. |
.:/opt/openshift/src:/opt/rh/php55/root/usr/share/pear |
|
Location for session data files. |
/tmp/sessions |
|
Path that defines the document root for your application (for example, /public). |
/ |
The following environment variable sets its equivalent property value in the opcache.ini file:
Variable Name | Description | Default |
---|---|---|
|
The OPcache shared memory storage size. |
16M |
|
How often to check script time stamps for updates, in seconds. 0 results in OPcache checking for updates on every request. |
2 |
You can also override the entire directory used to load the PHP configuration by setting:
Variable Name | Description |
---|---|
|
Sets the path to the php.ini file. |
|
Path to scan for additional .ini configuration files |
You can use a custom composer repository mirror URL to download packages instead of the default 'packagist.org':
Variable Name | Description |
---|---|
|
Set this variable to use a custom Composer repository mirror URL to download required packages during the build process. Note: This only affects packages listed in composer.json. |
If the DocumentRoot
of the application is nested in the source directory
/opt/openshift/src, you can provide your own .htaccess file to override
the default Apache behavior and specify how application requests should be
handled. The .htaccess file must be located at the root of the application
source.
Hot deployment allows you to quickly make and deploy changes to your application
without having to generate a new S2I build. In order to immediately pick up
changes made in your application source code, you must run your built image with
the OPCACHE_REVALIDATE_FREQ=0
environment variable.
For example, see the
oc new-app
command. You can use the
oc
env
command to update environment variables of existing objects.
You should only use this option while developing or debugging; it is not recommended to turn this on in your production environment. |
To change your source code in a running pod, use the
oc
rsh
command to enter the container:
$ oc rsh <pod_id>
After you enter into the running container, your current directory is set to /opt/app-root/src, where the source code is located.