#docker (2020-04)

docker

All things docker

Archive: https://archive.sweetops.com/docker/

2020-04-08

Shawn Petersen avatar
Shawn Petersen

Can someone explain the reasoning why all the buildspec.yml examples I see for AWS CodeBuild/CodePipeline have you push up 2 docker images to ECR?

like this: post_build: commands: - echo Build completed on date - echo Pushing the Docker images… # - docker push $REPOSITORY_URI:latest - docker push $REPOSITORY_URI:$IMAGE_TAG

I’m probably missing something basic here…

Zachary Loeber avatar
Zachary Loeber

Its the same image, just tagged twice

Zachary Loeber avatar
Zachary Loeber

once with the evil latest tag, another with your image_tag

Shawn Petersen avatar
Shawn Petersen

is there a better way to do it? All the examples I’ve seen use latest, but i’m open to a better way?

roth.andy avatar
roth.andy

The latest tag is good for examples and samples, but when you want to run something stable in production you shouldn’t use latest. You should pin to a specific tag.

Shawn Petersen avatar
Shawn Petersen

that makes sense. So should I just cut out the latest tag in the buildspec and just use the HASH?

roth.andy avatar
roth.andy

It is fine to still push a latest tag, just make sure you are always pushing an explicit version tag too

roth.andy avatar
roth.andy

The risk is on the user whether to use the latest tag, not the developer

Shawn Petersen avatar
Shawn Petersen

cool, thanks for the advice

Zachary Loeber avatar
Zachary Loeber

sry, I’m just in the habit of calling latest == evil as part of my smear campaign against the latest tag. There is a place for it though for certain

2
3
vFondevilla avatar
vFondevilla

You can pass the tag in the imagedefinitions.json

vFondevilla avatar
vFondevilla

So you don’t have to use the latest tag. More info in https://docs.aws.amazon.com/codepipeline/latest/userguide/file-reference.html

Image Definitions File Reference - CodePipeline

Reference for definitions files used by job workers in container source and deploy actions

2020-04-09

2020-04-20

Gabe avatar

Does anyone have experience with using instance storage vice EBS for EC2 instances in ECS? If so, was there any noticeable performance gain?

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Can’t speak for ECS specifically, but for K8S we noticed for machines pulling down docker images when new news came on line would max out the IOPS

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

using an EBS volume with provisioned iops eliminated these bottlenecks (but new ones - like the speed at which we could download docker images surfaced)

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

it was well over a year ago, so don’t recall the exact performance gains.

Gabe avatar

yeah we’ve had issues with iops so we were exploring using instance storage

Gabe avatar

but… amazon linux 2 doesn’t let you modify which volume docker uses

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

No problemo

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Have you tried `

mount --bind /big-ebs-volume/ /var/lib/docker/
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

that way you use the same folder structure and everything else keeps working

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

the key is you need to do this before the docker daemon starts or it will be corrupted

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

We previously did this on CoreOS and it worked. Came down to getting the systemd units dependency ordering correct.

this1
Marcin Brański avatar
Marcin Brański

Instance store will be faster than EBS. Much much faster. EBS is network constrained and provisioned IOPS cost much while instance store provides tens of thousands of IOPS for smaller instances up to millions. EBS is persistant storage though.

2020-04-21

2020-04-24

    keyboard_arrow_up