summaryrefslogtreecommitdiffstats
path: root/healthcheck-container
diff options
context:
space:
mode:
authorJack Lucas <jflos@sonoris.net>2023-07-17 12:03:09 -0400
committerJack Lucas <jflos@sonoris.net>2023-10-10 10:56:00 -0400
commite992a80969426810ac1939323e2f188be028c96b (patch)
tree056af1678b86972eac5de2314ab3f5385fd24acd /healthcheck-container
parentf815d0c940f10d2efbcaadd52a77f7432c5a942c (diff)
Update healthcheck to use newer node.js base image.2.4.1-healthcheck-container
Update base image to node 18.18.0, the latest LTS release. Issue-ID: DCAEGEN2-3400 Change-Id: I8a1ad5f4d2d5f36544a611eac6b58351ecd4daf1 Signed-off-by: Jack Lucas <jflos@sonoris.net>
Diffstat (limited to 'healthcheck-container')
-rw-r--r--healthcheck-container/Changelog.md5
-rw-r--r--healthcheck-container/Dockerfile4
-rw-r--r--healthcheck-container/README.md14
-rw-r--r--healthcheck-container/package.json2
-rw-r--r--healthcheck-container/pom.xml4
5 files changed, 18 insertions, 11 deletions
diff --git a/healthcheck-container/Changelog.md b/healthcheck-container/Changelog.md
index b64dc89..2cc7f23 100644
--- a/healthcheck-container/Changelog.md
+++ b/healthcheck-container/Changelog.md
@@ -4,6 +4,11 @@ All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](http://keepachangelog.com/)
and this project adheres to [Semantic Versioning](http://semver.org/).
+## [2.4.1] - 2023-10-10
+* [DCAEGEN2-3400] Update Docker base image to node.js 18.x (the latest LTS release).
+* Update README to eliminate references to dcaemod and the old dcaegen2 platform services,
+ which are no longer being deployed and which had separate instances of the healthcheck service.
+
## [2.4.0] - 2021-12-08
* [DCAEGEN2-2959] Add healthchecking for microservices deployed after DCAE installation.
diff --git a/healthcheck-container/Dockerfile b/healthcheck-container/Dockerfile
index cf93791..7e144c1 100644
--- a/healthcheck-container/Dockerfile
+++ b/healthcheck-container/Dockerfile
@@ -2,7 +2,7 @@
# org.onap.dcae
# ================================================================================
# Copyright (c) 2018-2020 AT&T Intellectual Property. All rights reserved.
-# Copyright (c) 2021 J. F. Lucas. All rights reserved.
+# Copyright (c) 2021, 2023 J. F. Lucas. All rights reserved.
# ================================================================================
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
@@ -17,7 +17,7 @@
# limitations under the License.
# ============LICENSE_END=========================================================
#
-FROM node:16.12.0-alpine3.14
+FROM node:18.18.0-alpine3.18
RUN mkdir -p /opt/app \
&& adduser -D -h /opt/app health
COPY *.js /opt/app/
diff --git a/healthcheck-container/README.md b/healthcheck-container/README.md
index fa08f64..1ce1b51 100644
--- a/healthcheck-container/README.md
+++ b/healthcheck-container/README.md
@@ -1,17 +1,19 @@
-# DCAE and DCAE MOD Healthcheck Service
+# DCAE Healthcheck Service
-The Healthcheck service provides a simple HTTP API to check the status of DCAE or DCAE MOD components running in the Kubernetes environment. When it receives any incoming HTTP request, the service makes queries to the Kubernetes API to determine the current status of the DCAE or DCAE MOD components, as seen by Kubernetes. Most components have defined a "readiness probe" (an HTTP healthcheck endpoint or a healthcheck script) that Kubernetes uses to determine readiness.
+The Healthcheck service provides a simple HTTP API to check the status of DCAE components running in the Kubernetes environment. When it receives any incoming HTTP request, the service makes queries to the Kubernetes API to determine the current status of the DCAE components, as seen by Kubernetes. Most components have defined a "readiness probe" (an HTTP healthcheck endpoint or a healthcheck script) that Kubernetes uses to determine readiness. The Healthcheck service itself does not directly connect to the DCAE components to check their status.
-Three instances of the Healthcheck service are deployed in ONAP: one for DCAE platform (dcaegen2, to be eliminated during the R10 development cycle), one for DCAE Helm-deployed microservices (dcaegen2-services), and one for DCAE MOD (dcaemod).
+A single instance of the DCAE Healthcheck service is deployed in ONAP.
The Healthcheck service has two sources for identifying components that should be running:
1. A list of components that are expected to be deployed by Helm as part of the ONAP installation, specified in a JSON array stored in a file at `/opt/app/expected-components.json`.
- dcaegen2, dcaegen2-services, and dcaemod have configurable deployments. By setting flags in the `values.yaml` file or in an override file, a user can select which components are deployed. The`/opt/app/expected-components.json` file is generated at deployment time based on which components have been selected for deployment. The file is stored in a Kubernetes ConfigMap that is mounted on the healthcheck container at `/opt/app/expected-components.json`. See the Helm charts for dcaegen2, dcaegen2-services, and dcaemod in the OOM repository for details on how the ConfigMap is created.
+ The DCAE ONAP deployment (using the OOM dcaegen2-services Helm charts) is configurable. By setting flags in the `values.yaml` file or in an override file, a user can select which components are deployed. The`/opt/app/expected-components.json` file is generated at deployment time based on which components have been selected for deployment. The file is stored in a Kubernetes ConfigMap that is mounted on the healthcheck container at `/opt/app/expected-components.json`. See the Helm charts for dcaegen2-services in the OOM repository for details on how the ConfigMap is created.
-2. Components whose Kubernetes deployments have been marked with the labeled specified by the environment variable `DEPLOY_LABEL`. These are identified by a query to the Kubernetes API requesting a list of all the deployments with the label. The query is made each time an incoming HTTP request is made, so that as new deployments are created, they will be detected and included in the health check.
+2. Components whose Kubernetes deployments have been marked with the label whose name is given by the environment variable `DEPLOY_LABEL`. The dcaegen2-services-common deployment template inserts this label into every deployment that uses the template. On every incoming HTTP request, the Healthcheck
+service queries the Kubernetes API to get a list of all the deployments that have this label. This allows the Healthcheck service to detect components that
+have been deployed after the initial DCAE ONAP deployment.
- For the dcaegen2-services instance of the Healthcheck service, the `DEPLOY_LABEL` variable is set to `dcaeMicroserviceName`. This is the label that the dcaegen2-services-common deployment template inserts into every deployment that uses the template. The dcaegen2-services Healthcheck instance therefore includes in its healthcheck all components deployed using the dcaegen2-services-common deployment template. For the dcaemod and dcaegen2 instances of the Healthcheck service, the `DEPLOY_LABEL` is not set, so the dcaemod and dcaegen2-services health checks do not make any checks based on a label.
+_Note that since the London release, having two methods for determining what components should be running is (arguably) redundant. The label method is (arguably)sufficient. The two methods are historical. At one time, as many as three different instances of the Healthcheck service ran in ONAP, and two of them did not have labeling. The counterargument for keeping the "expected components" test along with the labeling test is that if there is some error in the Helm charts that prevents a Kubernetes deployment being created for one of the "expected components", that expected component will not come up, but the healthcheck will not test for it._
The Healthcheck service returns an HTTP status code of 200 if Kubernetes reports that all of the components that should be running are in a ready state. It returns a status code of 500 if some of the components are not ready. It returns a status code of 503 if some kind of error prevented it from completing a query.
diff --git a/healthcheck-container/package.json b/healthcheck-container/package.json
index 4fd9cbb..33873b8 100644
--- a/healthcheck-container/package.json
+++ b/healthcheck-container/package.json
@@ -1,7 +1,7 @@
{
"name": "k8s-healthcheck",
"description": "DCAE healthcheck server",
- "version": "2.4.0",
+ "version": "2.4.1",
"main": "healthcheck.js",
"author": "author",
"license": "(Apache-2.0)"
diff --git a/healthcheck-container/pom.xml b/healthcheck-container/pom.xml
index 1f2b152..61b2278 100644
--- a/healthcheck-container/pom.xml
+++ b/healthcheck-container/pom.xml
@@ -3,7 +3,7 @@
============LICENSE_START=======================================================
Copyright (c) 2018-2020 AT&T Intellectual Property. All rights reserved.
Copyright (c) 2020 NOKIA Intellectual Property. All rights reserved.
-Copyright (c) 2021 J. F. Lucas. All rights reserved.
+Copyright (c) 2021, 2023 J. F. Lucas. All rights reserved.
================================================================================
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
@@ -29,7 +29,7 @@ limitations under the License.
<groupId>org.onap.dcaegen2.deployments</groupId>
<artifactId>healthcheck-container</artifactId>
<name>dcaegen2-deployments-healthcheck-container</name>
- <version>2.4.0</version>
+ <version>2.4.1</version>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>