Resolving services by logical names already eliminates a lot of configuration in the application. Since the same container image is being used in all environments, potentially different configuration needs to be inserted from the orchestration environment. As shown in the previous example, Kubernetes config maps tackle this situation. The hello-cloud application expects that at runtime a properties file will reside under /opt/config/application.properties. The project code will therefore access this location. The following demonstrates the integration of the properties file using a CDI producer:

public class HelloGreeter {

    @Inject
    @Config("hello.greeting")
    String greeting;

    @Inject
    @Config("hello.name")
    String greetingName;

    public String processGreeting() {
        return greeting + ", " + greetingName;
    }
}

The CDI producer is defined similarly to the configuration example shown previously:

@ApplicationScoped
public class ConfigurationExposer {

    private final Properties properties = new Properties();

    @PostConstruct
    private void initProperties() {
        try (InputStream inputStream =
                new FileInputStream("/opt/config/application.properties")) {
            properties.load(inputStream);
        } catch (IOException e) {
            throw new IllegalStateException("Could not init configuration", e);
        }
    }

    @Produces
    @Config("")
    public String exposeConfig(InjectionPoint injectionPoint) {
        Config config = injectionPoint.getAnnotated().getAnnotation(Config.class);
        if (config != null)
            return properties.getProperty(config.value());
        return null;
    }
}

The definition of the @Config qualifier is similar to the previous example in Chapter 3, Implementing Modern Java Enterprise Applications. The application loads the contents of the properties file into the properties map and produces the configured values using CDI. All managed beans can inject these values which emerge from the Kubernetes config map.

In order to realize secret configuration values, Kubernetes includes the concept of secrets as previously shown. A common practice is to make the contents of the secrets accessible in containers using environment variables.

Java applications use the System.getenv() method to access environment variables. This functionality is used for both secrets and config map values, respectively.

The demonstrated approaches and examples enable an enterprise application to be deployed, managed, and configured in a container orchestration cluster. They are sufficient for the majority of use cases.