Configuring AWS clients through LocalstackContainer.

[maciejwalkowiak]

Currently configuring AWS services pointing to Localstack container is quite cumbersome:

S3Client s3 = S3Client
    .builder()
    .endpointOverride(localstack.getEndpointOverride(Service.S3))
    .credentialsProvider(
        StaticCredentialsProvider.create(
            AwsBasicCredentials.create(localstack.getAccessKey(), localstack.getSecretKey())
        )
    )
    .region(Region.of(localstack.getRegion()))
    .build();

This could be heavily simplified if Localstack container exposed a method configure(S3Client.builder()) that would set credentials, endpoint and region. Currently I use hand-crafted solution (it does not cover edge cases) that ideally would end up in the LocalstackContainer:

public class LocalstackClientConfigurer {

    public static <T extends AwsClientBuilder<?, ?>> T configure(T builder, LocalStackContainer localstack) {
        builder.endpointOverride(getEndpoint(localstack))
                .credentialsProvider(
                        StaticCredentialsProvider.create(
                                AwsBasicCredentials.create(localstack.getAccessKey(), localstack.getSecretKey())
                        )
                )
                .region(Region.of(localstack.getRegion()));
        return builder;
    }

    private static URI getEndpoint(LocalStackContainer localstack) {
        return URI.create("http://" +  localstack.getHost() + ":" + localstack.getMappedPort(4566));
    }
}

Such configure method works with both sync and async clients from AWS SDK v2. Similar one could be added to support AWS SDK v1.

The problem is that it configure method would need to take a type from AWS SDK which violates the rule:

[ ] The module's public API should only handle standard JDK data types and MUST not expose data types that come from compileOnly dependencies. This is to reduce the risk of compatibility problems with future versions of third party libraries.

Do you consider any exceptions from this rule or perhaps suggest another way how this issue can be approached?

[eddumelendez]

Thanks for raising this topic @maciejwalkowiak ! Nowadays, it is true that some Testcontainers modules are providing some utility methods such as LocalStack (using AWS SDK V1), ToxiProxy. However, those have been deprecated due to Testcontainers' responsibility is container initialization and those will be removed in the next major version. How clients are used and built is the users' responsibility, and this is something Testcontainers would help with documentation and examples.

[maciejwalkowiak]

Got it 👍