Notes for Docker Installations Using GCP

The following section are additional notes for Docker installations using GCP.

  • The process/steps for pulling the image can be done manually as indicated. However, if you skip this step, it will be done automatically when running the deploy-master-gcp script. Note that the spin-up time will be slightly longer since all the images will need to be pulled as a part of the deployment process. So you'll see "CreatingContainer" for a few minutes until anything happens. Logs in local dashboard for the deployment will track progress on the pull requests
  • The deploy-slaves-gcp script is based on the Master deployment script, which has persistent storage. This is ideal for a Master, since it handles synchronizations between MOM and also contains local settings around sync times, etc. This may not be ideal for the Slave deployment script, particularly if you're testing or switching between different Mashery clusters within a K8s cluster. The persistent storage for Slaves will keep the original MOM Key/Secret used during the first deployment, which can lead to issues later on, if you switch to a new Master or cluster (for another POC/environment). You can always just manually delete the PVs (persistent volumes) for the Slaves but long term non-persistent seems to be the best option for Slaves.
  • Init logs for the containers (ML-CM, in particular) under /var/log/mashery/ are your most helpful way for troubleshooting why a container may not be fully initializing. For example, looking at these logs were used to determine that while a key/secret were being passed to MOM for authentication, the process was ultimately failing. This may have been due to explicitly defining a MOM-Host during the set-mom-secret script process. Deleting the existing secret, and re-creating/replacing it, helped the container to initialize without issues.
  • During initialization of the containers you may, almost immediately, see warnings or errors of persistent volume health checks failing. This is caused by health-check scripts running a little too quickly, which draws these flags. Give the containers a little more time (2 to 4 minutes on average for a decently equipped K8s cluster). You can refresh your dashboard or check "kubectl get pods" to see if all 4 containers come on line. The ML-CM (4th container) tends to take a little longer than the rest.