-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add source-to-image support #239
Conversation
[test-openshift] |
where's the assemble script? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing s2i/bin tree (probably just not added to the commit?) makes the tests fail at build stage.
source $default_dir/$filename | ||
fi | ||
done | ||
shopt -s nullglob |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be shopt -u nullglob
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, fixed.
3.2/Dockerfile
Outdated
@@ -27,6 +28,9 @@ RUN yum install -y centos-release-scl && \ | |||
rpm -V $INSTALL_PKGS && \ | |||
yum clean all | |||
|
|||
# Copy the S2I scripts from the specific language image to $STI_SCRIPTS_PATH. | |||
COPY s2i/bin/ $STI_SCRIPTS_PATH |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The s2i/bin/
tree is missing from git
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. Files are added.
$ s2i build ~/image-configuration/ centos/mongodb-32-centos7 my-mongodb-centos7 | ||
``` | ||
|
||
The directory passed to `s2i build` can contain these directories: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be more specific here: "...should contain one or more of the following directories:"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
@@ -0,0 +1,25 @@ | |||
# update_users creates default users (see usage) | |||
# if users are already created, updates passwords to match | |||
# environmental variables |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/environmental/environment/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
The directory passed to `s2i build` can contain these directories: | ||
- `mongodb-cfg/` | ||
- when running `run-mongod` or `run-mongod-replication` commands contained `mongod.conf` file is used for `mongod` configuration | ||
- `envsubst` command is run on this file to still allow customization of the image using environmental variables |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/environmental/environment/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
@@ -0,0 +1,23 @@ | |||
# check_env_vars checks environmental variables |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/environmental/environment/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
default_dir=$2 | ||
|
||
shopt -s nullglob | ||
for filename in $(echo $custom_dir/*.sh $default_dir/*.sh | xargs -r basename -a | sort | uniq); do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather use find
command instead of echo $dir | xargs...
e.g. find $custom_dir $default_dir -maxdepth 1 -type f -name '*.sh' -printf "%f\n" | sort -u
should do similar thing I hope. It will also allow removing the shopt -s nullglob
lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To really support spaces in filename (if some crazy man does it), we might do something like this:
find "$custom_dir" "$default_dir" -maxdepth 1 -type f -name '*.sh' -printf "%f\n" | sort -u | while read filename ; do ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When running for example process_extending_files ${APP_DATA}/mongodb-pre-init/ ${CONTAINER_SCRIPTS_PATH}/pre-init/
the user provided directory doesn't have to exist.
With shopt -s nullglob
echo $custom_dir/*.sh
prints nothing in this case. But find "$custom_dir"
returns 1 and prints error message.
@hhorak Would be using find
with checking that directories exists better?
Difference is that in current implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@omron93 I found this during mariadb PoC as well, this is how I solved it:
https://github.com/sclorg/mariadb-container/pull/32/files#diff-fe50a7af34bff8099d244f9c0cd56273R177
(I can't say that I'm very proud of running similar find command twice, but it works)
3.2/s2i/bin/assemble
Outdated
|
||
shopt -s dotglob | ||
echo "---> Installing application source ..." | ||
ls -A /tmp/a/* &>/dev/null && mv /tmp/src/* ./ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure whether I'm missing something or it is a typo -- shouldn't ls -A /tmp/a/
be rather ls -A /tmp/src/
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. It is typo - fixed.
- `mongodb-init/` | ||
- contained shell scripts (`*.sh`) are sourced when `mongod` server is started | ||
- in this phase `mongod` server don't have enabled authentication when running `run-mongod` command (for `run-mongod-replication` command configured users are already created and authentication is enabled) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should also include a simple example and typical use case for every directory. The use cases might be:
- changing a config option based on the environment variable (
mongodb-cfg
) - checking that admin password is longer than 16 bytes (additional restrictions) (
mongodb-pre-init
) - storing some initial documents (constants) into the database (
mongodb-init
)
These examples may be used for both, as a documentation and by the testing script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. I'll add example app configuration. And it should be also used in image tests.
- `mongodb-init/` | ||
- contained shell scripts (`*.sh`) are sourced when `mongod` server is started | ||
- in this phase `mongod` server don't have enabled authentication when running `run-mongod` command (for `run-mongod-replication` command configured users are already created and authentication is enabled) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When sourcing the scripts, some variables are defined and sometimes users may need them in their extension scripts. For example REPLICATION
to make things differently for replication use case and non-replication scenarios. I think we should be explicit about which variables users may use this way and consider all the other variables (even if available and set) to be an implementation detail only, so users don't depend on them. I'd start with most necessary variables only and add more when needed later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added. Please review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've provided few in-line comments, but generally this looks very nice IMO. We should gather broader feedback now.
3.2/s2i/bin/usage
Outdated
set -o nounset | ||
set -o pipefail | ||
|
||
man -l /help.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The /help.1
is meant to be formatted for atomic
tool that shows the help file using groff
tool. Using just pure groff
would also limit dependencies, since man
requires more deps. So, man -l /help.1
may be replaced by groff -man -ETascii /help.1
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
groff-base
should also be installed in the Dockerfile
, so we make sure it is available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for using groff instead of man. However we should use groff -t -man -ETascii /help.1
to properly format any tables located in the help file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for suggestion. Now should be done this way.
# process_files process extending files in $1 and $2 directories | ||
# - source all *.sh files | ||
# (if there are files with same name source only file from $1) | ||
function process_files() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
process_files
does not describe the function specifically enough, I'd rather use something like process_extending_files
as a function name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is better. Renamed.
3b700e0
to
98ab64f
Compare
Rebased. Changes:
|
3.2/s2i/bin/assemble
Outdated
|
||
shopt -s dotglob | ||
echo "---> Installing application source ..." | ||
ls -A /tmp/src/* &>/dev/null && mv /tmp/src/* ./ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the point of the ls?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To not to exit with mv error in case that no extending files are present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would use mv /tmp/src/* ./ 2>/dev/null || true
which is a bit more readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bparees Are files in /tmp/src/
always owned by current images user? (does s2i build
always set this?)
If not, mv /tmp/src/* ./ 2>/dev/null
could hide useful error message. But it is true that || true
is more readable.
Anyway, thanks for suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we always chmod the files to 666 as we layer them into the container, so permissions should not be a problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to what Petr suggested.
[test-openshift] |
Any update on this? It's needed for SNI according to #240 |
I think the SNI is good enough reason to not wait with this any more, let's merge it after rebasing. |
[test-openshift] |
@@ -0,0 +1 @@ | |||
/bin/run-mongod |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this take/respect args so you can start it w/ replication?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bparees What do you mean by this?
In majority of s2i based images run
script is used as default image CMD - it is not a mongodb case (it has different default CMD). So I've added this link mainly for "compatibility" reasons and expected that it won't be used. Is the assumption wrong, is something using specially /usr/libexec/run
?
Or is this comment related to #246 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes it's related to #246, but I guess it's ok at least for now. The entrypoint for the user-built image will be "container-entrypoint" still and the default command will be this run script, the user can change the command to "/bin/run-mongod-replication" if they want to use replication.
I can confirm via testing that creating ConfigMaps in OpenShift and then mounting I have built container from this PR (744cb94), pushed it to local OpenShift cluster(registry) and successfully deployed the container with custom configuration, which enabled ssl (similar to #239 (comment)). Note that pushing a custom container to the registry required a 'magic' workaround for some unknown reason. I will investigate that further later on. |
Hi, I test with image
`# oc logs -f mongodb-0 2017-07-25T09:29:38.334+0000 I STORAGE [initandlisten] exception in initAndListen: 12596 old lock file, terminating |
@dongboyan77 Thank you for the testing.
Are you changing only password in new pod? If you are changing both
Is this working with How can I test it myself? |
@omron93 ok, I change both MONGODB_USER and MONGODB_PASSWORD , so it's normal. I use this template https://github.com/sclorg/mongodb-container/blob/master/examples/petset/mongodb-petset-persistent.yaml |
possible to do this using s2i)
Removed section about mounting custom configuration file.
OK. Also basic scaling was working for me with this template. Then it is unrelated to this PR, so I've created new issue #249 |
This is very similar to the MongoDB PoC: sclorg/mongodb-container#239 It adds extending support using [source-to-image](https://github.com/openshift/source-to-image). For example to build customized MariaDB database image `my-mariadb-centos7` with configuration in `~/image-configuration/` run: ``` $ s2i build ~/image-configuration/ centos/mariadb-101-centos7 my-mariadb-centos7 ``` The directory passed to `s2i build` can contain these directories: - `mysql-cfg/` - when starting the container, files from this directory will be used as a configuration for the `mysqld` daemon - `envsubst` command is run on this file to still allow customization of the image using environmental variables - `mysql-pre-init/` - shell scripts (`*.sh`) available in this directory are sourced before `mysqld` daemon is started - `mysql-init/` - shell scripts (`*.sh`) available in this directory are sourced when `mysqld` daemon is started locally - in this phase, use `${mysql_flags}` to connect to the locally running daemon, for example `mysql $mysql_flags < dump.sql` Variables that can be used in the scripts provided to s2i: - `$mysql_flags` -- arguments for the `mysql` tool that will connect to the locally running `mysqld` during initialization - `$MYSQL_RUNNING_AS_MASTER` -- variable defined when the container is run with `run-mysqld-master` command - `$MYSQL_RUNNING_AS_SLAVE` -- variable defined when the container is run with `run-mysqld-slave` command - `$MYSQL_DATADIR_FIRST_INIT` -- variable defined when the container was initialized from the empty data dir During `s2i build` all provided files are copied into `/opt/app-root/src` directory into the resulting image. If some configuration files are present in the destination directory, files with the same name are overwritten. Also only one file with the same name can be used for customization and user provided files are preferred over default files in `/usr/share/container-scripts/mysql/`- so it is possible to overwrite them. Same configuration directory structure can be used to customize the image every time the image is started using `docker run`. The directory has to be mounted into `/opt/app-root/src/` in the image (`-v ./image-configuration/:/opt/app-root/src/`). This overwrites customization built into the image.
This is very similar to the MongoDB PoC: sclorg/mongodb-container#239 It adds extending support using [source-to-image](https://github.com/openshift/source-to-image). For example to build customized MariaDB database image `my-mariadb-centos7` with configuration in `~/image-configuration/` run: ``` $ s2i build ~/image-configuration/ centos/mariadb-101-centos7 my-mariadb-centos7 ``` The directory passed to `s2i build` can contain these directories: - `mysql-cfg/` - when starting the container, files from this directory will be used as a configuration for the `mysqld` daemon - `envsubst` command is run on this file to still allow customization of the image using environmental variables - `mysql-pre-init/` - shell scripts (`*.sh`) available in this directory are sourced before `mysqld` daemon is started - `mysql-init/` - shell scripts (`*.sh`) available in this directory are sourced when `mysqld` daemon is started locally - in this phase, use `${mysql_flags}` to connect to the locally running daemon, for example `mysql $mysql_flags < dump.sql` Variables that can be used in the scripts provided to s2i: - `$mysql_flags` -- arguments for the `mysql` tool that will connect to the locally running `mysqld` during initialization - `$MYSQL_RUNNING_AS_MASTER` -- variable defined when the container is run with `run-mysqld-master` command - `$MYSQL_RUNNING_AS_SLAVE` -- variable defined when the container is run with `run-mysqld-slave` command - `$MYSQL_DATADIR_FIRST_INIT` -- variable defined when the container was initialized from the empty data dir During `s2i build` all provided files are copied into `/opt/app-root/src` directory into the resulting image. If some configuration files are present in the destination directory, files with the same name are overwritten. Also only one file with the same name can be used for customization and user provided files are preferred over default files in `/usr/share/container-scripts/mysql/`- so it is possible to overwrite them. Same configuration directory structure can be used to customize the image every time the image is started using `docker run`. The directory has to be mounted into `/opt/app-root/src/` in the image (`-v ./image-configuration/:/opt/app-root/src/`). This overwrites customization built into the image.
This is very similar to the MongoDB PoC: sclorg/mongodb-container#239 It adds extending support using [source-to-image](https://github.com/openshift/source-to-image). For example to build customized MariaDB database image `my-mariadb-centos7` with configuration in `~/image-configuration/` run: ``` $ s2i build ~/image-configuration/ centos/mariadb-101-centos7 my-mariadb-centos7 ``` The directory passed to `s2i build` can contain these directories: - `mysql-cfg/` - when starting the container, files from this directory will be used as a configuration for the `mysqld` daemon - `envsubst` command is run on this file to still allow customization of the image using environmental variables - `mysql-pre-init/` - shell scripts (`*.sh`) available in this directory are sourced before `mysqld` daemon is started - `mysql-init/` - shell scripts (`*.sh`) available in this directory are sourced when `mysqld` daemon is started locally - in this phase, use `${mysql_flags}` to connect to the locally running daemon, for example `mysql $mysql_flags < dump.sql` Variables that can be used in the scripts provided to s2i: - `$mysql_flags` -- arguments for the `mysql` tool that will connect to the locally running `mysqld` during initialization - `$MYSQL_RUNNING_AS_MASTER` -- variable defined when the container is run with `run-mysqld-master` command - `$MYSQL_RUNNING_AS_SLAVE` -- variable defined when the container is run with `run-mysqld-slave` command - `$MYSQL_DATADIR_FIRST_INIT` -- variable defined when the container was initialized from the empty data dir During `s2i build` all provided files are copied into `/opt/app-root/src` directory into the resulting image. If some configuration files are present in the destination directory, files with the same name are overwritten. Also only one file with the same name can be used for customization and user provided files are preferred over default files in `/usr/share/container-scripts/mysql/`- so it is possible to overwrite them. Same configuration directory structure can be used to customize the image every time the image is started using `docker run`. The directory has to be mounted into `/opt/app-root/src/` in the image (`-v ./image-configuration/:/opt/app-root/src/`). This overwrites customization built into the image.
This is very similar to the MongoDB PoC: sclorg/mongodb-container#239 It adds extending support using [source-to-image](https://github.com/openshift/source-to-image). For example to build customized MariaDB database image `my-mariadb-centos7` with configuration in `~/image-configuration/` run: ``` $ s2i build ~/image-configuration/ centos/mariadb-101-centos7 my-mariadb-centos7 ``` The directory passed to `s2i build` can contain these directories: - `mysql-cfg/` - when starting the container, files from this directory will be used as a configuration for the `mysqld` daemon - `envsubst` command is run on this file to still allow customization of the image using environmental variables - `mysql-pre-init/` - shell scripts (`*.sh`) available in this directory are sourced before `mysqld` daemon is started - `mysql-init/` - shell scripts (`*.sh`) available in this directory are sourced when `mysqld` daemon is started locally - in this phase, use `${mysql_flags}` to connect to the locally running daemon, for example `mysql $mysql_flags < dump.sql` Variables that can be used in the scripts provided to s2i: - `$mysql_flags` -- arguments for the `mysql` tool that will connect to the locally running `mysqld` during initialization - `$MYSQL_RUNNING_AS_MASTER` -- variable defined when the container is run with `run-mysqld-master` command - `$MYSQL_RUNNING_AS_SLAVE` -- variable defined when the container is run with `run-mysqld-slave` command - `$MYSQL_DATADIR_FIRST_INIT` -- variable defined when the container was initialized from the empty data dir During `s2i build` all provided files are copied into `/opt/app-root/src` directory into the resulting image. If some configuration files are present in the destination directory, files with the same name are overwritten. Also only one file with the same name can be used for customization and user provided files are preferred over default files in `/usr/share/container-scripts/mysql/`- so it is possible to overwrite them. Same configuration directory structure can be used to customize the image every time the image is started using `docker run`. The directory has to be mounted into `/opt/app-root/src/` in the image (`-v ./image-configuration/:/opt/app-root/src/`). This overwrites customization built into the image.
This is very similar to the MongoDB PoC: sclorg/mongodb-container#239 It adds extending support using [source-to-image](https://github.com/openshift/source-to-image). For example to build customized MariaDB database image `my-mariadb-centos7` with configuration in `~/image-configuration/` run: ``` $ s2i build ~/image-configuration/ centos/mariadb-101-centos7 my-mariadb-centos7 ``` The directory passed to `s2i build` can contain these directories: - `mysql-cfg/` - when starting the container, files from this directory will be used as a configuration for the `mysqld` daemon - `envsubst` command is run on this file to still allow customization of the image using environmental variables - `mysql-pre-init/` - shell scripts (`*.sh`) available in this directory are sourced before `mysqld` daemon is started - `mysql-init/` - shell scripts (`*.sh`) available in this directory are sourced when `mysqld` daemon is started locally - in this phase, use `${mysql_flags}` to connect to the locally running daemon, for example `mysql $mysql_flags < dump.sql` Variables that can be used in the scripts provided to s2i: - `$mysql_flags` -- arguments for the `mysql` tool that will connect to the locally running `mysqld` during initialization - `$MYSQL_RUNNING_AS_MASTER` -- variable defined when the container is run with `run-mysqld-master` command - `$MYSQL_RUNNING_AS_SLAVE` -- variable defined when the container is run with `run-mysqld-slave` command - `$MYSQL_DATADIR_FIRST_INIT` -- variable defined when the container was initialized from the empty data dir During `s2i build` all provided files are copied into `/opt/app-root/src` directory into the resulting image. If some configuration files are present in the destination directory, files with the same name are overwritten. Also only one file with the same name can be used for customization and user provided files are preferred over default files in `/usr/share/container-scripts/mysql/`- so it is possible to overwrite them. Same configuration directory structure can be used to customize the image every time the image is started using `docker run`. The directory has to be mounted into `/opt/app-root/src/` in the image (`-v ./image-configuration/:/opt/app-root/src/`). This overwrites customization built into the image.
This is very similar to the MongoDB PoC: sclorg/mongodb-container#239 It adds extending support using [source-to-image](https://github.com/openshift/source-to-image). For example to build customized MariaDB database image `my-mariadb-centos7` with configuration in `~/image-configuration/` run: ``` $ s2i build ~/image-configuration/ centos/mariadb-101-centos7 my-mariadb-centos7 ``` The directory passed to `s2i build` can contain these directories: - `mysql-cfg/` - when starting the container, files from this directory will be used as a configuration for the `mysqld` daemon - `envsubst` command is run on this file to still allow customization of the image using environmental variables - `mysql-pre-init/` - shell scripts (`*.sh`) available in this directory are sourced before `mysqld` daemon is started - `mysql-init/` - shell scripts (`*.sh`) available in this directory are sourced when `mysqld` daemon is started locally - in this phase, use `${mysql_flags}` to connect to the locally running daemon, for example `mysql $mysql_flags < dump.sql` Variables that can be used in the scripts provided to s2i: - `$mysql_flags` -- arguments for the `mysql` tool that will connect to the locally running `mysqld` during initialization - `$MYSQL_RUNNING_AS_MASTER` -- variable defined when the container is run with `run-mysqld-master` command - `$MYSQL_RUNNING_AS_SLAVE` -- variable defined when the container is run with `run-mysqld-slave` command - `$MYSQL_DATADIR_FIRST_INIT` -- variable defined when the container was initialized from the empty data dir During `s2i build` all provided files are copied into `/opt/app-root/src` directory into the resulting image. If some configuration files are present in the destination directory, files with the same name are overwritten. Also only one file with the same name can be used for customization and user provided files are preferred over default files in `/usr/share/container-scripts/mysql/`- so it is possible to overwrite them. Same configuration directory structure can be used to customize the image every time the image is started using `docker run`. The directory has to be mounted into `/opt/app-root/src/` in the image (`-v ./image-configuration/:/opt/app-root/src/`). This overwrites customization built into the image.
* Implement source-to-image support This is very similar to the MongoDB PoC: sclorg/mongodb-container#239 It adds extending support using [source-to-image](https://github.com/openshift/source-to-image). For example to build customized MariaDB database image `my-mariadb-centos7` with configuration in `~/image-configuration/` run: ``` $ s2i build ~/image-configuration/ centos/mariadb-101-centos7 my-mariadb-centos7 ``` The directory passed to `s2i build` can contain these directories: - `mysql-cfg/` - when starting the container, files from this directory will be used as a configuration for the `mysqld` daemon - `envsubst` command is run on this file to still allow customization of the image using environmental variables - `mysql-pre-init/` - shell scripts (`*.sh`) available in this directory are sourced before `mysqld` daemon is started - `mysql-init/` - shell scripts (`*.sh`) available in this directory are sourced when `mysqld` daemon is started locally - in this phase, use `${mysql_flags}` to connect to the locally running daemon, for example `mysql $mysql_flags < dump.sql` Variables that can be used in the scripts provided to s2i: - `$mysql_flags` -- arguments for the `mysql` tool that will connect to the locally running `mysqld` during initialization - `$MYSQL_RUNNING_AS_MASTER` -- variable defined when the container is run with `run-mysqld-master` command - `$MYSQL_RUNNING_AS_SLAVE` -- variable defined when the container is run with `run-mysqld-slave` command - `$MYSQL_DATADIR_FIRST_INIT` -- variable defined when the container was initialized from the empty data dir During `s2i build` all provided files are copied into `/opt/app-root/src` directory into the resulting image. If some configuration files are present in the destination directory, files with the same name are overwritten. Also only one file with the same name can be used for customization and user provided files are preferred over default files in `/usr/share/container-scripts/mysql/`- so it is possible to overwrite them. Same configuration directory structure can be used to customize the image every time the image is started using `docker run`. The directory has to be mounted into `/opt/app-root/src/` in the image (`-v ./image-configuration/:/opt/app-root/src/`). This overwrites customization built into the image. * Implement source-to-image support This is very similar to the MongoDB PoC: sclorg/mongodb-container#239 It adds extending support using [source-to-image](https://github.com/openshift/source-to-image). For example to build customized MariaDB database image `my-mariadb-centos7` with configuration in `~/image-configuration/` run: ``` $ s2i build ~/image-configuration/ centos/mariadb-101-centos7 my-mariadb-centos7 ``` The directory passed to `s2i build` can contain these directories: - `mysql-cfg/` - when starting the container, files from this directory will be used as a configuration for the `mysqld` daemon - `envsubst` command is run on this file to still allow customization of the image using environmental variables - `mysql-pre-init/` - shell scripts (`*.sh`) available in this directory are sourced before `mysqld` daemon is started - `mysql-init/` - shell scripts (`*.sh`) available in this directory are sourced when `mysqld` daemon is started locally - in this phase, use `${mysql_flags}` to connect to the locally running daemon, for example `mysql $mysql_flags < dump.sql` Variables that can be used in the scripts provided to s2i: - `$mysql_flags` -- arguments for the `mysql` tool that will connect to the locally running `mysqld` during initialization - `$MYSQL_RUNNING_AS_MASTER` -- variable defined when the container is run with `run-mysqld-master` command - `$MYSQL_RUNNING_AS_SLAVE` -- variable defined when the container is run with `run-mysqld-slave` command - `$MYSQL_DATADIR_FIRST_INIT` -- variable defined when the container was initialized from the empty data dir During `s2i build` all provided files are copied into `/opt/app-root/src` directory into the resulting image. If some configuration files are present in the destination directory, files with the same name are overwritten. Also only one file with the same name can be used for customization and user provided files are preferred over default files in `/usr/share/container-scripts/mysql/`- so it is possible to overwrite them. Same configuration directory structure can be used to customize the image every time the image is started using `docker run`. The directory has to be mounted into `/opt/app-root/src/` in the image (`-v ./image-configuration/:/opt/app-root/src/`). This overwrites customization built into the image. * Report tests result properly * Add OpenShift tests File test-lib-openshift.sh is a candidate for container-common-scripts. * Fix test for s2i mount * Update common submodule and use test-lib-openshift.sh from that submodule * Add SSL connection testing * Add self-signed-ssl example
First implementation of s2i support to allow extending this image.
I'll add documentation on Thursday.
@hhorak @praiskup @pkubatrh Please take a look and comment.