Download the PHP package ibexa/docker without Composer

On this page you can find all versions of the php package ibexa/docker. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package docker

Docker blueprints

This package contains unsupported docker building blocks used for some of automated functional testing infrastructure at Ibexa. Feel free to copy it for own use or look to it for some recommended settings.

Be aware of the following limitations:

WARNING, made mainly for automation: The tools within this directory are meant for use in test automation, QA, Support and demo use cases, and with time as a blueprint for how to best configure your own setup. You are free to use and adopt them for your needs, and we more than welcome contributions to improve it.

WARNING, low performance on MacOS and Windows: For reasons mentioned above, these tools are not optimized for use as development environment with MacOS or Windows, and are affected by known I/O performance issues caused by Docker for MacOS/Windows use of shared folders. This is a known issue and we don't intend to add complexity to work around it.

Overview

This setup currently requires Docker Compose 1.14 and Docker 17.06 or higher. Defaults are set in .env, and files to ignore are set in .dockerignore. By default, .env specifies that the dev setup is used.

Note: For this and other reasons all docker-compose commands must be executed from root of your project directory.

Before you begin: Install Docker & Docker-Compose

Before going through the steps below, make sure you have recent versions of Docker and Docker Compose installed on your machine.

For Windows you also need to install bash, or adapt instructions below for Windows command line where needed.

Concept: Docker Compose "Building blocks" for Ibexa DXP

The current Docker Compose files are made to be mixed and matched together for QA/Support use cases. Currently available:

You can use these file with the -f argument on docker-compose, like:

However below environment variable COMPOSE_FILE is used instead since this is also what is used to have a default in .env file at root of the project.

Project setup

Demo "image" use

Using this approach, everything runs in containers and volumes. This means that if you for instance upload a image using the Ibexa DXP backend, that image ends up in a volume, and not below public/var/ in your project directory.

From the root of your project's clone of this distribution, set up composer auth.json and execute the following:

After about 5-10 seconds you should be able to browse the site on localhost:8080 and the backend on localhost:8080/admin.

Development "mount" use

When you use this approach, your project directory is bind-mounted into the Nginx and PGP containers. If you change a PHP file in, for instance src, that change is applied in automatically.

Warning: Dev setup works a lot faster on Linux then on Windows/Mac where Docker uses virtual machines with shared folders by default under the hood, which leads to much slower IO performance.

From the root of your project's clone of this distribution, set up composer auth.json and execute the following:

After about 5-10 seconds you should be able to browse the site on localhost:8080 and the backend on localhost:8080/admin.

_TIP: If you are seeing 500 errors, or in the case of APP_ENV=dev database exceptions, then make sure to comment out database_* params in app/config/parameters.yml to make sure env variables are used correctly._

Behat and Selenium use

Docker Compose setup for Behat use is provided and used internally to test Ibexa DXP. It can be combined with most setups, here shown in combination with production setup which is what you typically need to test before pushing your image to Docker Hub/Registry.

From the root of your project's clone of this distribution, set up composer auth.json and execute the following:

The last step is to execute Behat scenarios using app container which now has access to web and Selenium containers, for example:

Tip: You can typically re-run the installation command to get back to a clean installation between Behat runs by using:

Note: if you want to use the Chromium driver, use:

This driver is not fully supported in our test suite and is in experimental state.

DFS

If you want to use the DFS cluster handler, you need to run the migration script manually, after starting the containers ( run docker-compose up -d --force-create first).

The migration script copies the binary files in public/var to the nfs mount point (./dfsdata) and adds the files' metadata to the database. If your are going to run Ibexa DXP in a cluster you must then ensure that ./dfsdata is a mounted nfs share on every node/app container.

Once this is done, you may delete public/var/* if you don't intend to run the migration scripts ever again.

Production use

Example: Building app with php image

In this example we'll build a app image which includes both php (php_fpm) and the Ibexa DXP application and run them in a swarm cluster using docker stack.

Prerequisite:

In this example we assume your swarm manager is named swarmmanager and that this hostname resolves on all swarm hosts. We also assume that the nfs server and docker registry are running on swarmmanager.

All the commands below should be executed on your swarmmanager

Example: Separating app and php

In this alternative way of running Ibexa DXP, the Ibexa DXP code and PHP executables are separated in two different images. The upside of this is that it gets easier to upgrade PHP (or any other distro applications) independently of Ibexa DXP. To do it, replace the PHP container with an updated one without having to rebuild the Ibexa DXP image. The downside of this approach is that all Ibexa DXP code is copied to a volume so that it can be shared with other containers. This means bigger disk space footprint and longer loading time of the containers. It is also more complicated to make this approach work with docker stack so only a docker-compose example is provided.

Further info

Configuring Composer

For Composer to run correctly as part of the build process, you need to create a auth.json file in your project root with your GitHub readonly token:

For further information on tokens for updates.ibexa.co, see the installation guide.

Debugging

For checking logs from the containers themselves, use docker-compose logs. Here on app service, but can be omitted to get all:

You can login to any of the services using docker-compose exec, here shown against app image and using bash:

To display running services:

Database dumps

Database dump is placed in doc/docker/entrypoint/mysql/. This folder is used my mysql/mariadb which executes everything inside the folder. This means there should only be data represent one install in the folder at any given time.

Updating service images

To updated the used service images, you can run:

This assumed you either use docker-compose -f or have COMPOSE_FILE defined in cases where you use something else then defaults in .env.

After this you can re run the production or dev steps to setup containers again with updated images.

Cleanup

Once you are done with your setup, you can stop it, and remove the involved containers.

And if you have defined any environment variables you can unset them using:

COPYRIGHT

Copyright (C) 1999-2024 Ibexa AS (formerly eZ Systems AS). All rights reserved.

LICENSE

This source code is available separately under the following licenses:

A - Ibexa Business Use License Agreement (Ibexa BUL), version 2.4 or later versions (as license terms may be updated from time to time) Ibexa BUL is granted by having a valid Ibexa DXP (formerly eZ Platform Enterprise) subscription, as described at: https://www.ibexa.co/product For the full Ibexa BUL license text, please see:

AND

B - GNU General Public License, version 2 Grants an copyleft open source license with ABSOLUTELY NO WARRANTY. For the full GPL license text, please see:


All versions of docker with dependencies

PHP Build Version
Package Version
No informations.
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package ibexa/docker contains the following files

Loading the files please wait ....