Skip to content

Commit

Permalink
Merge pull request #84 from OpenLiberty/staging
Browse files Browse the repository at this point in the history 
Merge staging to prod - changes from Bindu Umesh (#83)
  • Loading branch information
@gkwan-ibm
gkwan-ibm authored Aug 14, 2024
2 parents b23cb4f + f09bf46 commit b0d2eba
Showing 1 changed file with 18 additions and 18 deletions.
36 changes: 18 additions & 18 deletions README.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -79,11 +79,11 @@ include::finish/query/pom.xml[]

The `system` microservice contains the three Maven build profiles: [hotspot=development file=0]`dev`, [hotspot=testing file=0]`test`, and [hotspot=prod file=0]`prod`, in which the [hotspot=defaultProfile file=0]`dev` profile is set as the default. Each build profile defines properties for a particular deployment configuration that the microservice uses.

The MicroProfile Config configuration profile feature supplies configurations for different environments while only a single profile is active. The active profile is set using the `mp.config.profile` property. You can set it in any of the https://openliberty.io/docs/latest/external-configuration.html#default[configuration sources^] and it is read once during application startup. When a profile is active, its associated configuration properties are used. For the `query` service, the `mp.config.profile` property is set to [hotspot=mp.config.profile file=1]`dev` in its Maven `pom.xml`. This Liberty configuration variable indicates to the runtime that `dev` is the active configuration profile.
The MicroProfile Config configuration profile feature supplies configurations for different environments when only a single profile is active. The active profile is set using the `mp.config.profile` property. You can set it in any of the https://openliberty.io/docs/latest/external-configuration.html#default[configuration sources^] and it is read once during application startup. When a profile is active, its associated configuration properties are used. For the `query` service, the `mp.config.profile` property is set to [hotspot=mp.config.profile file=1]`dev` in its Maven `pom.xml`. This Liberty configuration variable indicates to the runtime that `dev` is the active configuration profile.

When you run Open Liberty in https://openliberty.io/docs/latest/development-mode.html[dev mode^], the dev mode listens for file changes and automatically recompiles and deploys your updates whenever you save a new change.

Open a command-line session and run the following commands to navigate to the `system` directory and start the `system` service in `dev` environment:
Open a command-line session and run the following commands to navigate to the `system` directory and start the `system` service in the `dev` environment:

ifndef::cloud-hosted[]
[role='command']
Expand All @@ -99,7 +99,7 @@ mvn liberty:dev
```
endif::[]

Open another command-line session and run the following commands to navigate to the `query` directory and start the `query` service in `dev` environment:
Open another command-line session and run the following commands to navigate to the `query` directory and start the `query` service in the `dev` environment:

ifndef::cloud-hosted[]
[role='command']
Expand Down Expand Up @@ -146,18 +146,18 @@ endif::[]

The `query` service returns the message: `{"fail":"Failed to reach the client localhost."}`. This is because the current `query` service uses the default properties in the [hotspot file=2]`query/src/main/resources/META-INF/microprofile-config.properties` file to access the `system` service.

For proper communication with the development `system` service, the `query` service uses the properties in the `dev` configuration profile.
For proper communication with the development `system` service, the `query` service uses properties in the `dev` configuration profile.

image::system-query-devops-development.png[System service running in development environment,align="center",width=85%,height=85%]

There are two ways to define configuration properties associated with your configuration profile. The first is as individual configuration properties associated with a configuration profile that can be specified in any kind of MicroProfile configuration source. The second is through default `microprofile-config.properties` configuration files embedded inside your application that can be associated with different configuration profiles. The former allows for flexibility in defining profile-specific configuration properties in the best configuration sources for your needs while the latter enables default profiles of configuration properties to be provided in your application.
There are two ways to define configuration properties that are associated with your configuration profile. The first is as individual configuration properties associated with a configuration profile that can be specified in any kind of MicroProfile configuration source. The second is through default `microprofile-config.properties` configuration files embedded in your application that can be associated with different configuration profiles. The former allows for flexibility in defining profile-specific configuration properties in the best configuration sources for your needs while the latter enables default profiles of configuration properties to be provided in your application.

// =================================================================================================
// Configuring properties at the property level
// =================================================================================================
=== Creating profile-specific configuration properties

This approach involves directly associating individual configuration properties with a configuration profile. To define a configuration property for a particular config profile, use the `%<config_profile_id>.<property_name>=<value>` syntax, where `<config_profile_id>` is the unique identifier for the configuration profile and `<property_name>` is the name of the property you want to set.
This approach involves directly associating individual configuration properties with a configuration profile. To define a configuration property for a particular config profile, use the `%<config_profile_id>.<property_name>=<value>` syntax, where `<config_profile_id>` is the unique identifier for the configuration profile and `<property_name>` is the name of the property that you want to set.

[role="code_command hotspot file=0", subs="quotes"]
----
Expand All @@ -181,9 +181,9 @@ include::finish/system/pom.xml[]

Configure the [hotspot=development file=0]`%dev.*` properties in the `microprofile-config.properties` file based on the values from the [hotspot=developmentProperties file=1]`dev` profile of the `system` service.

Because the active profile is set to `dev`, each `%dev.*` property overrides the value of the plain non-profile-specific property. For example, in this case the [hotspot=dev.port file=0]`%dev.system.httpsPort` property overrides the [hotspot=port file=0]`system.httpsPort` property and the value is resolved to `9444`.
Because the active profile is set to `dev`, each `%dev.*` property overrides the value of the plain non-profile-specific property. For example, in this case, the [hotspot=dev.port file=0]`%dev.system.httpsPort` property overrides the [hotspot=port file=0]`system.httpsPort` property and the value is resolved to `9444`.

Because you are running the `query` service in dev mode, the changes that you made are automatically picked up.
Because you are running the `query` service in dev mode, the changes that you made are automatically picked up.

ifndef::cloud-hosted[]
Try out the application at the http://localhost:9085/query/systems/localhost URL. You can see the current OS and Java version in JSON format.
Expand All @@ -202,7 +202,7 @@ endif::[]
// =================================================================================================
=== Creating profile-specific `microprofile-config.properties` configuration files

Creating profile-specific `microprofile-config.properties` configuration files is a structured way to provide and manage more extensive sets of default configurations. You can create a configuration file for each configuration profile in the `META-INF` folder on the classpath of your application by using the `microprofile-config-<config_profile_id>` naming convention, where `<config_profile_id>` is the unique identifier for a configuration profile. Once you create the file, you can add your configuration properties to it with the standard `<property_name>=<value>` syntax.
Creating profile-specific `microprofile-config.properties` configuration files is a structured way to provide and manage more extensive sets of default configurations. You can create a configuration file for each configuration profile in the `META-INF` folder on the classpath of your application by using the `microprofile-config-<config_profile_id>` naming convention, where `<config_profile_id>` is the unique identifier for a configuration profile. After you create the file, you can add your configuration properties to it with the standard `<property_name>=<value>` syntax.

ifdef::cloud-hosted[]
Open another command-line session.
Expand Down Expand Up @@ -265,7 +265,7 @@ Now, click the following button to try out the application again:
You can see the current OS and Java version in JSON format.
endif::[]

When you are done checking out the application in `dev` environment, exit dev mode by pressing `CTRL+C` in the command-line sessions where you ran the `system` and `query` services.
When you are done checking out the application in `dev` environment, exit dev mode by pressing `CTRL+C` in the command-line sessions where you ran the `system` and `query` services.

// =================================================================================================
// Creating a configuration profile for the test environment
Expand Down Expand Up @@ -314,7 +314,7 @@ include::finish/query/src/test/java/it/io/openliberty/guides/query/QueryEndpoint

Implement endpoint tests to test the basic functionality of the `query` microservice. If a test failure occurs, you might have introduced a bug into the code.

See the following descriptions of the test cases:
See the following descriptions of test cases:

* [hotspot=testQuerySystem file=2]`testQuerySystem()` verifies the `/query/systems/{hostname}` endpoint.

Expand Down Expand Up @@ -406,7 +406,7 @@ To further explore deploying microservices using Kubernetes and the Open Liberty
* https://openliberty.io/guides/openliberty-operator-intro.html[Deploying a microservice to Kubernetes using Open Liberty Operator^]
* https://openliberty.io/guides/openliberty-operator-openshift.html[Deploying a microservice to OpenShift 4 using Open Liberty Operator^]

A secure production environment is essential to application security. In the previous sections, you learned how to use the MicroProfile Config API to externalize credentials and other properties for accessing the `system` service. This strategy makes the application more adaptable to different environments without the need to change code and rebuild your application.
A secure production environment is essential for application security. In the previous sections, you learned how to use the MicroProfile Config API to externalize credentials and other properties for accessing the `system` service. This strategy makes the application more adaptable to different environments without the need to change code and rebuild your application.

In the this section, you'll learn how to use Kubernetes secrets to provide the credentials and how to pass them to the `query` service by using MicroProfile Config.

Expand Down Expand Up @@ -471,9 +471,9 @@ docker build -t query:1.0-SNAPSHOT query/.
```
endif::[]

The Maven `clean` and `package` goals can clean the `target` directories and build the `.war` application files from scratch. The [hotspot=mp-config-dev file=3]`microprofile-config-dev.properties` and [hotspot=mp-config-test file=3]`microprofile-config-test.properties` of the `query` microservice are excluded from the [hotspot=prod file=3]`prod` build. The default [hotspot file=4]`microprofile-config.properties` file is automatically applied.
The Maven `clean` and `package` goals can clean the `target` directories and build the `.war` application files from scratch. The [hotspot=mp-config-dev file=3]`microprofile-config-dev.properties` and [hotspot=mp-config-test file=3]`microprofile-config-test.properties` files of the `query` microservice are excluded from the [hotspot=prod file=3]`prod` build. The default [hotspot file=4]`microprofile-config.properties` file is automatically applied.

The Docker `build` commands package the `.war` files of the [hotspot=config hotspot=war file=1]`system` and [hotspot=config hotspot=war file=2]`query` microservices with their default configuration into your Docker images.
The Docker `build` command packages the `.war` files of the [hotspot=config hotspot=war file=1]`system` and [hotspot=config hotspot=war file=2]`query` microservices with their default configuration into your Docker images.

ifndef::cloud-hosted[]
After building the images, you can create a Kubernetes secret for storing sensitive data such as credentials.
Expand Down Expand Up @@ -525,7 +525,7 @@ endif::[]

If you want to override another property, you can specify it in the `env` sections of the `deploy.yaml` file. For example, set the [hotspot=context.root file=5]`CONTEXT_ROOT` environment variable in the `system` deployment and the [hotspot=system.contextRoot file=5]`SYSTEM_CONTEXTROOT` environment variable in the `query` deployment.

Once the images and the secret are ready, you can deploy the microservices to your production environment with Kubernetes.
After the images and the secret are ready, you can deploy the microservices to your production environment with Kubernetes.

ifndef::cloud-hosted[]
[source, role="no_copy"]
Expand All @@ -542,7 +542,7 @@ When the apps are deployed, run the following command to check the status of you
kubectl get pods
```

You'll see an output similar to the following if all the pods are healthy and running:
You'll see an output similar to the following example if all the pods are healthy and running:

```
----
Expand All @@ -563,7 +563,7 @@ Open another command-line session and access the microservice by running the fol
curl -k -s "https://localhost:9448/query/systems/system.${SN_ICR_NAMESPACE}.svc" | jq
```

You'll see an output similar to the following:
You'll see an output similar to the following example:

```
{
Expand All @@ -573,7 +573,7 @@ You'll see an output similar to the following:
}
```

When you're done trying out the microservice, press **CTRL+C** in the command line session where you ran the `kubectl port-forward` command to stop the port forwarding, and then delete all resources by running the following commands:
After trying out the microservice, press **CTRL+C** in the command line session where you ran the `kubectl port-forward` command to stop the port forwarding, and then delete all resources by running the following commands:
```bash
cd /home/project/guide-microprofile-config-profile/start
kubectl delete -f deploy.yaml
Expand Down

0 comments on commit b0d2eba

Please sign in to comment.