Profile Architecture Ideas - mikemilano/kalabox GitHub Wiki

The Kalabox webkit app installs on the user's local system and provides a user configuration space under: ~/kalabox. (for this example anyway. Also, this is not the same config as in the codebase.)

Kalabox will also keep a directory on the docker host in sync with this config directory. Let's say the path on the Docker host is: /srv/kalabox/config.

Kalabox creates user applications based on profiles. A profile defines data about a site, including what roles are required for the app.

Core profiles will exist in the codebase config/profiles directory and user profiles may be added to ~/kalabox/profiles`.

A role is a service that will be fulfilled by a Docker image. For example, a PHP app may require nginx, php-fpm, and mysql roles. The PHP app profile will define an array of roles, along with a recommended image or build source for each role.

Example Profile:

{
  "title": "Drupal 8",
  "name": "drupal-8",
  "roles": [
    {
      "name": "nginx",
      "image": "kalabox/nginx"
    },
    {
      "name": "php-fpm",
      "images": "kalabox/php-fpm"
    },
    {
      "name": "mysql",
      "images": "kalabox/mysql"
    }
  ]
}

When an application instance is created, the profile config is copied to an application directory on the Docker host.

The Docker images will be launched with the project directory mapped as a volume in each container to: /kalabox (exact dir name is not important.. this is just for example)

The images would be configured or symlinked if needed, so that the respective service is loading its config from this directory. This provides a single place for an application to be configured once instantiated.

/srv/kalabox/apps/my-d8-app
/srv/kalabox/apps/my-d8-app/code
/srv/kalabox/apps/my-d8-app/config.json
/srv/kalabox/apps/my-d8-app/config/nginx.conf
/srv/kalabox/apps/my-d8-app/config/php.ini
/srv/kalabox/apps/my-d8-app/config/my.cnf
/srv/kalabox/apps/my-d8-app/data

These are the Docker host paths. /srv/kalabox/apps/my-d8-app is mapped to /kalabox in each container.

The profile defines roles and recommended images, but custom images maybe defined as well. This could happen at the time the app is being instantiated or later.

/srv/kalabox/apps/my-d8-app/config.json would just need to be updated with the appropriate images defined for each role. For example, if there is an image up on dockerhub, mmilano/nginx, config.json would be updated accordingly.

{
  "title": "Drupal 8",
  "name": "drupal-8",
  "roles": [
    {
      "name": "nginx",
      "image": "mmilano/nginx"
    },
    ...
  ]
}

Images can be setup to be built rather than pulled. (Maybe that should be default behavior anyway)

If you would like the images to be built from a dockerfile, set "build": "true" in the config file.

{
  "title": "Drupal 8",
  "name": "drupal-8",
  "roles": [
    {
      "name": "nginx",
      "image": "mmilano/nginx"
      "build": "true"
    },
    ...
  ]
}

If you do not define a source, the system will look for a Dockerfile in the following locations, in this order:

<project dir>/code/dockerfiles/mmilano/nginx
<project dir>/dockerfiles/mmilano/nginx
/srv/kalabox/config/dockerfiles/mmilano/nginx
<kalabox source>/config/dockerfiles/mmilano/nginx

Alternatively, you could provide a src property with a path relative to the application config for the Dockerfile. i.e. "src": "code/foo/nginx" would map to <project dir>/code/foo/nginx.

All this should provide ample flexibility to define custom dockerfiles at the Kalabox core, profile, or application levels.

There needs to be a component which handles the containers that make up an app.

One idea that might be worth exploring is to make each profile, and ultimately application a nodejs app with the tasks managed with a nodejs task manager like Grunt or Gulp.

There would be default tasks which every app would require, such as initialize, start, stop, restart, yet more custom tasks could be defined at the profile or application level.

A big advantages here would be the re-use of an existing plugin system.

There could be a REST service on top which is used to remotely execute the tasks per application.