a) Avoid using latest tag in Base Images

Using latest tag in the Build Base Image and in Runtime Base Image can lead to inconsistent build and run time build behaviors respectively.

b) Enable debugging or verbose mode in build scripts

In order for the build logs to be appears in the container builds, the pre-build and build scripts must print the execution steps in the console. If this is a /bin/sh script, you can set -x option to print the execution steps in the console.

#!/bin/sh
set -x
go build main.go

c) Long Running Containers

Containers move to completed state as soon as the start script completes. In order to make the containers to run as long running process, the last command in the start script can wait or watch on a status. In the below example, if for some reason, the sampleService fails, the container will still continue to run. You can login to the container terminal for further debugging.

#!/bin/sh
sampleService& > service.log
tail -f service.log

d) Ways of gathering Container Logs

Any logs printed within the Container Console will be automatically gathered by gopaddle and will be available under the Services / Replicas / Container Logs in a running application.

An alternate approach is to add a side car container like fluentd to the main container with a shared folder, so that the logs can be redirect to an ELK stack.

d) Adding Healthchecks for predictable container functionality

Adding a Healthcheck validates if the container is functionally ready. If the container is not ready, Kubernetes will restart the container until the healthcheck succeeds. gopaddle adds both a liveliness and a readiness probe based on the healthcheck added. If a Container and its corresponding Service goes down, you can set alert to notify the status.