You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 29, 2023. It is now read-only.
dbdeployer should be able to deploy docker containers with almost the same syntax used to deploy local sandboxes.
INTERFACE
The deployment interface for this extension could be one of the following:
dbdeployer deploy --docker {single|replication} 5.7.22. This has the advantage of reusing all the options already defined for sandbox deployment. A minor inconvenience would be disabling the options that aren't applicable to containers.
dbdeployer docker-deploy {single|replication} 5.7.22. The advantage here is that we define only the options that are relevant for containers, although there will be many duplications.
As for working with the containers, dbdeployer would create the same directory used for local sandboxes, with the same scripts, which will allow to access the container with the same ease. Of course, the contents of the scripts need to change to access the containers appropriately.
INFRASTRUCTURE
Deploying containers presents challenges different from the ones faced with sandboxes. We need to detect the IP address of the container for further usage (e.g. to set up replication) and forward container ports to normal ones.
A properly defined container needs the following customization volumes:
data directory: redirected to the ./data directory of the sandbox;
socket directory: redirected to the new ./var directory;
user initialization scripts: placed in /docker-entrypoint-initdb.d/;
This extension requires the adaptation of many templates to be used with containers. Some of them, however, will work well just the way they are now, due to the port forwarding that will enable the client to reach the database in the current host.
An important point is where to get the client from. I'd like to avoid using docker exec whenever possible, and therefore we could use the client from MySQL tarball binaries (same as with local sandboxes) with the server running in a container. If an appropriate MySQL client (= same version or higher than the server) cannot be found in the local host, we need to fall back to docker exec.
With the implementation of imported sandboxes this feature has become easier to come by. Yet, it is still difficult to come up with a seamless integration.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
dbdeployer should be able to deploy docker containers with almost the same syntax used to deploy local sandboxes.
INTERFACE
The deployment interface for this extension could be one of the following:
dbdeployer deploy --docker {single|replication} 5.7.22
. This has the advantage of reusing all the options already defined for sandbox deployment. A minor inconvenience would be disabling the options that aren't applicable to containers.dbdeployer docker-deploy {single|replication} 5.7.22
. The advantage here is that we define only the options that are relevant for containers, although there will be many duplications.As for working with the containers, dbdeployer would create the same directory used for local sandboxes, with the same scripts, which will allow to access the container with the same ease. Of course, the contents of the scripts need to change to access the containers appropriately.
INFRASTRUCTURE
Deploying containers presents challenges different from the ones faced with sandboxes. We need to detect the IP address of the container for further usage (e.g. to set up replication) and forward container ports to normal ones.
A properly defined container needs the following customization volumes:
./data
directory of the sandbox;./var
directory;/docker-entrypoint-initdb.d/
;Practical considerations
This extension requires the adaptation of many templates to be used with containers. Some of them, however, will work well just the way they are now, due to the port forwarding that will enable the client to reach the database in the current host.
An important point is where to get the client from. I'd like to avoid using
docker exec
whenever possible, and therefore we could use the client from MySQL tarball binaries (same as with local sandboxes) with the server running in a container. If an appropriate MySQL client (= same version or higher than the server) cannot be found in the local host, we need to fall back todocker exec
.Cc: @jaypipes
The text was updated successfully, but these errors were encountered: