Nginx

Nginx Application Stack

NGINX is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. NGINX is known for its high performance, stability, rich feature set, simple configuration, and low resource consumption. This application stack can produce deployment-ready containers for the SCALE environment.

The containers produced in this application stack share common requirements with other application stacks deployed to the SCALE environment. These shared requirements include:

• Security scanning for any vulnerabilities
• Code coverage scanning for test quality
• Staging of the application container in the appropriate Docker container repositories and tagged according to SCALE conventions
• Completion of Unit Testing and User Acceptance Testing
• Gated approvals before allowing deployments into pre-production and production environments
• Audit trail and history of deployment within the SCALE CI/CD Pipeline

Because of the above-listed requirements, the Nginx application stack is provided in order to support the build web applications in a manner that integrates with SCALE requirements and processes. The flow of deployment includes first a Continuous Integration stage of processing in a pipeline prior to deployment in the Continuous Deployment stages. The Continuous Integration stage focuses on building the application, running scans to check for test coverage and security vulnerabilities, and staging the container in the appropriate Docker repository ready for deployment. Subsequent pipeline stages deploy the application to the appropriate target Kubernetes spaces.

For details on getting started, see getting started.

For details on repository structure, see repository structure.

The source directory will contain documents context, defaulting to index.html with a welcome message from SCALE. The manifests directory contains Kustomize manifests if Kustomize overlay files are used as an alternative to Helm charts.

For details on application configuration, see application configuration.

Application Logging

Certain log format guidelines should be followed in order to ensure the capture of logs. All logging from the application should go to standard output (also sometimes referred to as "console" in the context of common logging libraries). In order for log entries to be picked up and collected into the logging collection infrastructure (Splunk), the log entries must match a particular format. That format looks like the following:

[ISO8601-Date] logLevel=level pid=pid thread=thread class=logger-class message=free-style-message where:

• level is the logging level (INFO, WARN, etc.)

• pid is the process ID

• thread is the thread ID

• logger-class is the class calling the logger (indicates where in the code the log message was issued)

• free-style-message is any addition logging content

The format can be further extended by adding additional key=value pairs before the free-style log message.

For details on CI/CD pipelines, see CI/CD pipelines.

For details on upgrading to Pipeline v4.7, see upgrading to Pipeline v4.7.

For details on pipeline definition, see pipeline definition.

Configuration and Customization of the Nginx Pipeline

Global Variables

The variables YAML object defines simple variables accessible across the pipeline logic. For Nginx pipelines, there is one required variable: appVersion, which specifies the version of the container to be pulled from Artifactory. The name of the container will match the name of the application defining the pipeline.

Application-Specific Pipeline Configuration

The extends YAML object is a complex object consisting of additional YAML objects. This object is used to extend the pipeline logic (referenced by the repository defined in the resources object) by (a) referencing the correct appstack pipeline entry point (devops/nginx.yml for the Nginx pipeline) and (b) passing a set of YAML objects as parameters to influence the behavior of the pipeline to meet an application teams specific needs.

The extends YAML object consists of 2 objects beneath it:

• template
• parameters

The template YAML object is a single value set to the initial entry point for the pipeline for the Nginx appstack, so it should always be defined as follows:

extends:
  template: pipeline/nginx/init.yml@templates

For details on defining hostspaces, see defining hostspaces.

For details on skipping deployments, see skipping deployments.

How to update nginx version

Update builderImage version property in azure-pipelines.yaml file for the variable extends/nginx/baseImgage

• baseImage - Source image to be pulled from Artifactory or docker-hub

extends:
  template: pipeline/nginx/init.yml@templates
  appVersion: 4.7.x
  nginx:
    baseImage: ${{ coalesce(parameters.nginx.baseImage,'library/nginx:stable-alpine') }}

Logging

nginx AppStack is pre-configured for splunk log aggregation. nginx Stdout and access log is tagged with app_log and common_log source type. Refer chart-dir/templates/deployment.yaml

metadata:
    annotations:
        collectord.io/index: "app" #Three letter app code
        collectord.io/logs-source: "/var/log/nginx.out"
        collectord.io/logs-type: "app_log"
        collectord.io/logs-extraction: '^\[(?P<timestamp>[^\]]+)\].+$'
        collectord.io/logs-timestampfield: timestamp
        collectord.io/logs-timestampformat: '2019-06-03 05:41:49.598'
        collectord.io/logs-eventpattern: '^\['
        collectord.io/volume.1-logs-name: 'logs'
        collectord.io/volume.1-logs-index: "app" #Three letter app code
        collectord.io/volume.1-logs-type: 'access_common'
    spec:
        template:
            spec:
            volumes:
            - name: logs
                emptyDir: {}
            containers:
            - name: "chart-name"
                env:
                - name: ACCESS_LOG
                value: /var/log/access
                volumeMounts:
                - name: logs
                mountPath: /var/log/access

Refer application.yaml for log pattern

server:
  tomcat:
    accesslog:
      directory: '${ACCESS_LOG::/tmp/access}'
      enabled: true
      rotate: false

logging:
  pattern:
    console: '[%date{ISO8601}] logLevel=%level pid=${PID:-} thread=%thread class=%logger{40} message="%msg"%n'

For details on Horizontal Pod Autoscaler, see Horizontal Pod Autoscaler.

For details on PVC for application stacks, see PVC for application stacks.

DR changes

With the introduction of pipeline v4.7, we have implemented DR capabilities that require changes in the Helm chart. Please refer to the document below for the necessary modifications and kindly update your Helm chart accordingly.

Getting Started with DR

Please refer to the following document to prepare your codebase for disaster recovery.

DR Config Map and Ingress Setup

For details on Pod Anti-Affinity, see Pod Anti-Affinity.

For details on detailed pipeline configuration, see detailed pipeline configuration.

For details on Kubernetes deployment objects, see Kubernetes deployment objects.

For details on troubleshooting, see troubleshooting.