Skip to content

Latest commit

 

History

History
37 lines (28 loc) · 2.27 KB

README.md

File metadata and controls

37 lines (28 loc) · 2.27 KB
Raw

Cloudping

See: README.rst for old readme from the forked repo. It may have some relevant bits of info, but otherwise is not kept up to date.

This repository contains a lambda function cloudping.py which we send cloudwatch events to as triggers. The function then pings the passed in domains, and publishes a metric based on the result of said ping. This allows us to regularly monitor all our domains.

Docker Environment

The .docker folder contains scripts & a Dockerfile. This is to containerize an easy-to-maintain-or-modify python environment. This means it has no chance to mess up your local python setup, nor does it have need of an opinion on the multidude of ways to manage python virtualenvs/pyenvs.

The script names are fairly self-explanatory.

  • .docker/bash.sh opens a bash shell inside the container.
  • .docker/python.sh opens a python shell inside the container.
  • .docker/up.sh brings up the container (and will build it if necessary, or pull from Docker cache). This step also copies your local aws keys into the container so that the container can run aws cli commands or boto usage. We also kill any old container if exists, so you can spam this .docker/up.sh to ensure you have an up to date container when returning to this repo in the future.
  • .docker/down.sh kills the container.
  • .docker/run_tests.sh runs the tests inside the container. These tests are from the original forked repo and have not been modified much, if at all. They are nice to have, but are not particularly robust. However, all this repo does is ping endpoints and pushes a metric, so it is relatively simple to smoketest live by deploying and peeking at the logs, and in the event cloudpinger breaks, no user or servers are effected (alarms may go off, however).

Deploying

The .deploy/deploy.sh script will deploy the cloudping function to each of the aws lambda cloudping functions we have. If we add one to another region some day, we should only need to copy a deployment line with the new region and it should work. This script creates a deployment package first (necessary to include requests module), which we then add our lambda function into the deploy package zip. When the deploy package is ready, we simply push our zip up to our functions to deploy the new code.