As you’ve probably guessed by Docker posts, I’m a huge fan of containerisation. Therefore instead of installing Prometheus on a host, let’s instead spin it up in a container. As described on the Prometheus website, we can accomplish this by issuing only a single command:
docker run -p 9090:9090 -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus
Let’s break down each component of this command to make sure we fully understand what it is doing:
docker run: Spin up a container
-p 9090:9090: Bind a port on our Docker host to a container port. This enables devices outside of the Docker host to reach the container on port 9090
-v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml: Binds the
/tmp/prometheus.yml file stored on the Docker host to
/etc/prometheus/prometheus.yml inside of the container
<user_account>/<container_name> that we want to use
If you’ve used Grafana, or even heard of it, chances are you’ve also heard of InfluxDB and Prometheus too. As I haven’t touched on the latter yet, I figured now is a good time to start. In case you haven’t heard of some, or all of these applications, let’s start off with a quick description on what they can do for us.
Note: You might also want to have a read of the My Monitoring Journey: Cacti, Graphite, Grafana & Chronograf post too.
Grafana is a frontend web app that is used to create beautiful dashboards. It does this by retrieving metrics which are stored on backend database servers such as InfluxDB, Prometheus MySQL, PostgreSQL and Graphite (to name just a few). It then uses metrics to create graphs which are displayed on the aforementioned dashboards.
In the previous post we may have started running before we could walk. In this post we’ll first take a few steps back to make sure we cover the basics before diving deeper.
Building an image
When we examined the
python:3.6.3-alpine3.6 image’s dockerfile, we saw the components which are used to create a Docker image:
- A single
OK, so we already know that the
FROM alpine3.6 command means that the Python image is going to use the Apline 3.6 as its Linux operating system.
ENV, as its name suggests, is used to specify environment variables for the image. That leaves us with
For those new to Docker, you’re probably wondering – What is it exactly?
“Docker is the company driving the container movement and the only container platform provider to address every application across the hybrid cloud.”
OK, it’s the name of a company. The next question is, what are containers? Rather than give you another quote, I’ll give you my own definition…
What are containers?
Containers are like portable executables. You know, the applications that come as a standalone
exe file and don’t require installation? I draw this comparison for the following reasons:
When you’re developing on two different OS’ (e.g Windows & Linux), the last thing you want to do is have to remember which tools to use on which system. I think we’d all agree that life would be a lot easier if we had a seamless experience between the two. That is where nano comes in to play.
As the GitHub page says, “Boto3 is the Amazon Web Services (AWS) Software Development Kit (SDK) for Python, which allows Python developers to write software that makes use of services like Amazon S3 and Amazon EC2.”
The good news is that Boto 3 is extremely well documented. However, the bad news is that it is quite difficult to follow. The documentation starts with a Quickstart guide, followed by a Sample Tutorial followed then by Code Examples. This is all good stuff, though it doesn’t give you much of an understanding of how to actually use Boto 3. For example, we see things such as:
# Create CloudWatch client
cloudwatch = boto3.client('cloudwatch')
# Get the service resource
sqs = boto3.resource('sqs')
But we haven’t yet learned what a client and a resource is, nor do we see sessions mentioned until much later in the documentation. But I digress. Let’s go ahead and get started!
In the Git: Keeping in sync post we learned how to merge the
orgin/master commits into our local
master branch. Then in Git: Effective branching using workflows we learned about how to use branches effectively. What we haven’t yet touched on yet though is rebasing and its affect on merging.
Before we get started on merging and rebasing, let’s first see how we can view our
git log as we will need to do it throughout this post:
Will@MainPC MINGW64 /f/Will/git-tutorial (master)
$ git log --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all -3
0a37254 - (4 days ago) Merge remote-tracking branch 'origin/test_branch' - Will Robinson (HEAD -> master, origin/master, develop)
a0ec1b6 - (4 days ago) removed file1.txt - Will Robinson (origin/test_branch)
740a573 - (4 days ago) Add new file - Will
In a nutshell, the above command shows us the last three commits which were made in this repo. If we want to get a little fancier, we can have git draw a graph for us:
Will@MainPC MINGW64 /f/Will/git-tutorial (master)
$ git log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all -3
* 0a37254 - (4 days ago) Merge remote-tracking branch 'origin/test_branch' - Will Robinson (HEAD -> master, origin/master, develop)
| * a0ec1b6 - (4 days ago) removed file1.txt - Will Robinson (origin/test_branch)
| * 740a573 - (4 days ago) Add new file - Will
In the Getting started with git we learned about local and remote branches (
origin/master respectively), and in Git: Keeping in sync we learned how to keep the two branches in sync. This is all great stuff, but if you’re working in a team and/or on a serious project, using only the
master branch is not a good idea. The reason being that if
master is having development code pushed to it continuously, it will never be stable.
What you should do instead, at a minimum, is have two branches. For example,
dev is used for features which are being developed and
master is used for production code. Once the in-development features have been tested and are ready for production, they can then be merged into
master. By employing this method
master will always be in a stable state.
In the Getting start with git post we covered a number of things, one of which was using
push to send our commits to a remote git repo. This is works fine when both of these conditions are met:
- You’re the only person working on the project
- You’re doing all of your development from the same machine
If one of these points is not true, you’ll soon find the
push command fails to work. The reason for this is because you must first retrieve all of the commits from the remote branch before you can merge your own. In other words, you must first be in sync before you can make modifications.
Therefore if someone does a
push before you, and/or you do a
push from a different machine, the machine you’re currently using will be out of sync with the remote branch. As a result you will be unable to do a
push until you first re-sync with the remote branch.
Note: The reason why this issue is not encountered when you meet the two criterion listed above is because your machine will always be in sync with the remote branch given that it’s the only one doing any commits.
Let’s now run through an example to see this in action.
What is git?
Wikipedia has a great answer for this question:
Git is a version control system for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source code management in software development, but it can be used to keep track of changes in any set of files. As a distributed revision control system it is aimed at speed, data integrity, and support for distributed, non-linear workflows.
OK cool, now that we know what is git let’s now take a look at git repositories.
What is a Repository (repo)?
A repository is receptacle for files which are part of a project. Each project should be stored in a separate repository so that their files are kept separate, access to them can be administered separately, etc.
Creating a new repo
When you create a new repo using a git server provided by the likes of GitHub and GitLab, you will be given a few options to help you get started. One of these options is as follows:
git clone firstname.lastname@example.org:OzNetNerd/git-tutorial.git
git add README.md
git commit -m "add README"
git push -u origin master