Used a different base image for MySQL.

This `mysql/mysql-server` official image from the Oracle MySQL team is smaller and starts faster than the Docker "official" `mysql` image. It's also far simpler to wait for startup to complete (the `mysql` image initializes MySQL, stops it, then restarts it, so the "ready" messages appear twice, making it very difficult for the the docker maven plugin to wait reliably).
This commit is contained in:
Randall Hauch 2015-11-18 15:14:30 -06:00
parent 0a99ed67cd
commit fd9e04552c
7 changed files with 29 additions and 16 deletions

View File

@ -1,6 +1,25 @@
Requirements
== Requirements
The following software is required to build Debezium locally:
* [JDK 8](http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html) or [OpenJDK 8](http://openjdk.java.net/projects/jdk8/)
* [Maven 3.2.1](https://maven.apache.org/index.html) or later
* [Docker Engine 1.4](http://docs.docker.com/engine/installation/) or later
See the links above for installation instructions on your platform.
=== Docker
Many open source software projects use Java and Maven, but requiring Docker is less common. Debezium is designed to talk to a number of external systems, such as various databases and services, and our integration tests verify Debezium does this correctly. But rather than expect you have all of these software systems installed locally, Debezium's build system uses Docker to automatically download or create the necessary images and start containers for each of the systems. The integration tests can then use these services and verify Debezium behaves as expected, and when the integration tests finish, Debezum's build will automatically stop any containers that it started.
Debezium also has a few modules that are not written in Java, and so they have to be required on the target operating system. Docker lets our build do this using images with the target operating system(s) and all necessary development tools.
Using Docker has several advantages:
1. You don't have to install, configure, and run specific versions of each external services on your local machine, or have access to them on your local network. Even if you do, Debezium's build won't use them.
1. We can test multiple versions of an external service. Each module can start whatever containers it needs, so different modules can easily use different versions of the services.
1. Everyone can run complete builds locally. You don't have to rely upon a remote continuous integration server running the build in an environment set up with all the required services.
1. All builds are consistent. When multiple developers each build the same codebase, they should see exactly the same results -- as long as they're using the same or equivalent JDK, Maven, and Docker versions. That's because the containers will be running the same versions of the services on the same operating systems. Plus, all of the tests are designed to connect to the systems running in the containers, so nobody has to fiddle with connection properties or custom configurations specific to their local environments.
1. No need to clean up the services, even if those services modify and store data locally. Docker *images* are cached, so building them reusing them to start containers is fast and consistent. However, Docker *containers* are never reused: they always start in their pristine initial state, and are discarded when they are shutdown. Integration tests rely upon containers, and so cleanup is handled automatically.
* JDK 8
* Maven 3.2.1 or later
* Docker 1.4 or later

View File

@ -104,7 +104,7 @@ public String username(String defaultValue) {
setProperties.accept(props);
}
Connection conn = DriverManager.getConnection(url, props);
LOGGER.info("Connected to {} with properties: {}",url, props);
LOGGER.info("Connected to {} with {}",url, props);
return conn;
}

View File

@ -109,15 +109,8 @@
<color>yellow</color>
</log>
<wait>
<!--
This is about as good as we can do with this base image. When this message is output
to the log, the container has not yet restarted `mysqld`, and so if the integration
tests run quickly enough they may run before the server has indeed started.
But on a decent laptop, this consistently works.
-->
<log>MySQL init process done. Ready for start up.</log>
<!-- No more than 20 seconds -->
<time>20000</time>
<time>30000</time> <!-- 30 seconds max -->
</wait>
</run>
</image>

View File

@ -1,4 +1,4 @@
FROM mysql:5.7
FROM mysql/mysql-server:5.7
MAINTAINER Debezium Community

View File

@ -8,4 +8,4 @@ log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} %-5p %m (%c)%n
log4j.rootLogger=INFO, stdout
# Set up the default logging to be INFO level, then override specific units
log4j.logger.io.debezium=INFO, stdout
log4j.logger.io.debezium=INFO

View File

@ -104,6 +104,7 @@
</log>
<wait>
<log>PostgreSQL init process complete; ready for start up.</log>
<time>30000</time> <!-- 30 seconds max -->
</wait>
</run>
</image>

View File

@ -8,4 +8,4 @@ log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} %-5p %m (%c)%n
log4j.rootLogger=INFO, stdout
# Set up the default logging to be INFO level, then override specific units
log4j.logger.io.debezium=INFO, stdout
log4j.logger.io.debezium=INFO