Writing a Dev Service
前提条件
-
You should already have an extension structure in place
-
You should have a containerised version of your external service (not all Dev Services rely on containers, but most do)
Creating a Dev Service
If your extension provides APIs for connecting to an external service, it’s a good idea to provide a Dev Service implementation.
To create a Dev Service, add a new build step into the extension processor class that returns a DevServicesResultBuildItem.
Here, the hello-world image is used, but you should set up the right image for your service.
@BuildStep(onlyIfNot = IsNormal.class, onlyIf = GlobalDevServicesConfig.Enabled.class)
public DevServicesResultBuildItem createContainer() {
DockerImageName dockerImageName = DockerImageName.parse("hello-world");
GenericContainer container = new GenericContainer<>(dockerImageName)
.withExposedPorts(SERVICE_PORT, OTHER_SERVICE_PORT)
.waitingFor(Wait.forLogMessage(".*" + "Started" + ".*", 1))
.withReuse(true);
container.start();
String newUrl = "http://" + container.getHost() + ":" + container.getMappedPort(SERVICE_PORT);
Map<String, String> configOverrides = Map.of("some-service.base-url", newUrl);
return new DevServicesResultBuildItem.RunningDevService(FEATURE, container.getContainerId(),
container::close, configOverrides)
.toBuildItem();
}With this code, you should be able to see your container starting if you add your extension to a test application and run quarkus dev.
However, the application will not be able to connect to it, because no ports are exposed. To expose ports, add withExposedPorts to the container construction.
For example,
GenericContainer container = new GenericContainer<>(dockerImageName)
.withExposedPorts(SERVICE_PORT, OTHER_SERVICE_PORT);Testcontainers will map these ports to random ports on the host. This avoids port conflicts, but presents a new problem – how do applications connect to the service in the container?
To allow applications to connect, the extension should override the default configuration for the service with the mapped ports. This must be done after starting the container. For example,
container.start();
Map<String, String> configOverrides = Map.of("some-service.base-url",
"http://" + container.getHost() + ":" + container.getMappedPort(SERVICE_PORT));Other configuration overrides may be included in the same map.
Waiting for the container to start
You should add a .waitingFor call to the container construction, to wait for the container to start. For example
.waitingFor(Wait.forLogMessage(".*" + "Started" + ".*", 1))Waiting for a port to be open is another option. See the Testcontainers documentation for a full discussion of wait strategies.
Configuring the Dev Service
To configure the Dev Service launch process, your build step can accept a ConfigPhase.BUILD_TIME config class in its constructor.
For example,
@BuildStep(onlyIfNot = IsNormal.class, onlyIf = GlobalDevServicesConfig.Enabled.class)
public DevServicesResultBuildItem createContainer(MyConfig config) {You may wish to use this config to set a fixed port, or set an image name, for example.
if (config.port.isPresent()) {
container.setPortBindings(List.of(config.port.get() + ":" + SERVICE_PORT));
}Controlling re-use
In dev mode, with live reload, Quarkus may restart frequently. By default, this will also restart test containers. Quarkus restarts are usually very fast, but containers may take much longer to restart. To prevent containers restarting on every code change, you can mark the container as reusable:
.withReuse(true)Some Dev Services implement sophisticated reuse logic in which they track the state of the container in the processor itself. You may need this if your service has more complex requirements, or needs sharing across instances.
