Compose Dev Services MS SQL connection url fix

[ozangunalp]

Tested with the following service definition:

services:
  mssql_db:
    image: mcr.microsoft.com/azure-sql-edge:latest
    labels:
      io.quarkus.devservices.compose.wait_for.logs: .*Recovery is complete.*
    cap_add:
      - SYS_PTRACE
    environment:
      ACCEPT_EULA: "Y"
      MSSQL_SA_PASSWORD: "bigStrongPwd1"
      MSSQL_DATA_DIR: /var/opt/mssql/customdata
    volumes:
      - sqldata:/var/opt/mssql/customdata
    ports:
      - "1433"
    restart: unless-stopped
volumes:
  sqldata:

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 13ec08e.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[github-actions]

🎊 PR Preview a0659db has been successfully built and deployed to https://quarkus-pr-main-48335-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 13ec08e.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[gsmet]

/cc @vsevel

[vsevel]

I am spending time on it to validate right now

[vsevel]

tested and OK with:

  mssql:
    image: mcr.microsoft.com/mssql/server:2022-latest
    ports:
      - "1433"
    environment:
      ACCEPT_EULA: "Y"
      MSSQL_SA_PASSWORD: Quarkus123
    labels:
      io.quarkus.devservices.compose.wait_for.ports.disable: true
      io.quarkus.devservices.compose.wait_for.logs: .*Recovery is complete.*

I was surprised to have to set trustServerCertificate=true:

  datasource:
    db-kind: "mssql"
    jdbc:
      additional-jdbc-properties:
        trustServerCertificate: true

[ozangunalp]

IIRC you can also add the parameter on the service definition side with a label io.quarkus.devservices.compose.jdbc.parameters: trustServerCertificate=true.

[gsmet]

@ozangunalp I think @vsevel 's point was more that this option is required when using Dev Services? Or am I mistaken?

[vsevel]

yes. I am surprised that the encrypt option would be on by default, specially for a dev service
did not have the time to search if this comes from the base image, from testcontainers or from devservices

[ozangunalp]

It should come from the image used and we cannot do anything about it. Compose services are just run as the given definition, we are just taking extra steps to make sure they are "ready", and to wire the application to use the exposed service.

[vsevel]

in testcontainers MSSQLServerContainer I see:

    @Override
    protected String constructUrlForConnection(String queryString) {
        // The JDBC driver of MS SQL Server enables encryption by default for versions > 10.1.0.
        // We need to disable it by default to be able to use the container without having to pass extra params.
        // See https://github.com/microsoft/mssql-jdbc/releases/tag/v10.1.0
        if (urlParameters.keySet().stream().map(String::toLowerCase).noneMatch("encrypt"::equals)) {
            urlParameters.put("encrypt", "false");
        }
        return super.constructUrlForConnection(queryString);
    }

apparently we skip this?

[vsevel]

I guess this is expected. in compose we get the options from the labels, not from testcontainers, and we configure them in:

public class MSSQLDatasourceServiceConfigurator implements DatasourceServiceConfigurator {
...
    @Override
    public String getJdbcUrl(ContainerAddress containerAddress, String databaseName) {
        return String.format("jdbc:%s://%s:%d%s",
                getJdbcPrefix(),
                containerAddress.getHost(),
                containerAddress.getPort(),
                getParameters(containerAddress.getRunningContainer().containerInfo().labels()));
    }

needs to be adressed in #48324

[ozangunalp]

This kind of configuration you need to do on the service definition. We enable that through labels.