Kubernetes Up & Running: Chapter 2

Page 16

1. make sure you’ve cloned the git repo mentioned earlier in the chapter

2. once in the repo, run:

make build

to build the application.

3. create this Dockerfile (not the one mentioned in the book)

MAINTAINER is deprecated. Use a LABEL instead: https://github.com/kubernetes-up-and-running/kuard/issues/7

And the  COPY path in the book is incorrect.

and run

docker build -t kuard-amd64:1 .

to build the Dockerfile.

Here we’ve got a repo name of kuard-amd64 and a tag of 1.

https://docs.docker.com/engine/reference/commandline/build/#tag-an-image–t

4. Check the repo using

docker images

Note: a registry is a collection of repositories, and a repository is a collection of images

https://docs.docker.com/get-started/part2/#recap-and-cheat-sheet-optional

 

Page 19

docker tag kuard-amd64:1 gcr.io/kuar-demo/kuard-amd64:1

According to https://docs.docker.com/get-started/part2/#tag-the-image

the tag command is:

docker tag image username/repository:tag

so image is kuard-amd64:1

but what’s the username?

Is it gcr.io ?

Or gcr.io/kuar-demo?

The answer is that Docker’s docs here:

https://docs.docker.com/get-started/part2/#tag-the-image

are incorrect. You don’t need a username or repository. It’s just a label. E.g. see https://docs.docker.com/engine/reference/commandline/tag/

Correct would be:

docker tag image <any label you want>:tag

BUT for the purposes of pushing to a repository that label DOES need to be of a specific format. i.e. username/image_name.

https://stackoverflow.com/questions/41984399/denied-requested-access-to-the-resource-is-denied-docker

Shame they didn’t explain that in more detail.

 

And the next line is misleading too.

docker push gcr.io/kuar-demo/kguard-amd64:1

This creates the impression that you’re pushing your image to a website (or registry) hosted at gcr.io.

It’s not.

It’s just the tag you created above. Having said that, I had to simplify the tag (from 2 slashes to 1 slash) to get it to work. E.g.

docker tag kuard-amd64:1 snowcrasheu/kuard-amd64:1

The reason for

denied: requested access to the resource is denied

is that (from https://stackoverflow.com/questions/41984399/denied-requested-access-to-the-resource-is-denied-docker )

https://stackoverflow.com/questions/41984399/denied-requested-access-to-the-resource-is-denied-docker

 

To login with docker use:

docker login

or to use a specific username / password.

docker login -u <username> -p <password>

Better is --password-stdin however.

and push with:

docker push snowcrasheu/kuard-amd64:1

which you should then be able to see on Docker Hub. E.g.

https://hub.docker.com/r/snowcrasheu/kuard-amd64/

 

Notes:

How to change a repository name: 

https://stackoverflow.com/questions/25211198/docker-how-to-change-repository-name-or-rename-image/25214186#25214186

 

AWS Config

Note: AWS Config records and evaluates configurations of your AWS resources.

You set up a bucket, a SNS topic and some rules.

The state of your AWS resources are stored and, if a non-compliant resource gets created, you get notified via the SNS topic.

Example rules might be:

  • Only SSL requests on S3 buckets
  • Logging enabled on S3 buckets
  • Versioning enabled on S3 buckets
  • Volumes are encrypted
  • SSH restricted: i.e. only a restricted set of IPs are allowed to access via SSH

https://aws.amazon.com/config/

 

Note: AWS Config is expensive.

AWS Control Tower

AWS Control Tower automates the set-up of a baseline environment, or landing zone, that is a secure, well-architected multi-account AWS environment.

Announced at re:Invent 2018.

https://aws.amazon.com/blogs/aws/aws-previews-and-pre-announcements-at-reinvent-2018-andy-jassy-keynote/

https://aws.amazon.com/controltower/

 

Uses AWS Config (expensive).

Note: AWS Config records and evaluates configurations of your AWS resources.

https://aws.amazon.com/config/

Write-ahead log

A write-ahead log ensures data integrity.

The idea is that changes to data files (i.e. your db tables) are only done after those changes have been logged.

This is really useful when you’ve got HA scenarios with multiple databases as trying to write data files sequentially is a pain whereas logs are always sequential so are easy to write.

WAL results in a significantly reduced number of disk writes, because only the log file needs to be flushed to disk to guarantee that a transaction is committed, rather than every data file changed by the transaction. The log file is written sequentially, and so the cost of syncing the log is much less than the cost of flushing the data pages. This is especially true for servers handling many small transactions touching different parts of the data store. Furthermore, when the server is processing many small concurrent transactions, one fsync of the log file may suffice to commit many transactions.

Note: this means journaled file systems are not necessary for reliable storage of the data files.

See: https://www.postgresql.org/docs/9.1/wal-intro.html

and

https://stackoverflow.com/questions/14181180/why-do-sql-databases-use-a-write-ahead-log-over-a-command-log