#docker (2018-11)

Hi People, does anyone know a good and proper way to remove layers with secrets from a docker image ? e.g. the only way that this can be done currently is to use multi stage builds or to unset the ENV/ARGS and there’s this blog post here that mentions experimental secrets but not for strings https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066 TL;DR docker history <docker_images> exposes layers with secrets from build time.

@Nikola Velkovski did you look at https://github.com/goldmann/docker-squash

here a a post how to do it https://blog.tomecek.net/post/docker-build-with-secrets/

Nope, thanks will have a look.

I also found this https://docs.docker.com/develop/develop-images/build_enhancements/#new-docker-build-command-line-build-output which is more or less what the blog post is saying

i believe it’s also possible to squash an image without any thirdparty tools

docker build --squash

https://docs.docker.com/engine/reference/commandline/image_build/#usage

You can also have an internal proxy that you use in your build process

that proxy then has the authentication token for github

we wrote one for the docker registry to do this

so we could pull images without authentication in a trusted environment

same concept would apply to github

here’s the simple service

https://gist.github.com/osterman/55edc4af91370f2ff1327af8b434c6fa

(you’d adapt something like this to proxy github requests instead)

DUPE: ~@Nikola Velkovski~heck this out~<https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066~

~Posted just a few days ago… highly relevant~

Ah yeah, I already read it and posted it yesterday

hahah

sorry, missed that! you did post it

Anyway thanks for the help, I was also under the impression that passing secrets as args is ok

luckily I haven’t pushed any public images

so regarding that experimental feature, that would be the cleanest, no?

yes

https://github.com/wagoodman/dive

Has anyone used docker as a test environment for starting/stopping services using their init manager? I can’t figure out why none of the “your-favorite-OS-in-docker” images… support their standard init process / service manager.

None of the vendor images (amazon 1 or 2, ubuntu) include their init system: (upstart, systemd, sysvinit) [ to their credit, CentOS does includes instructions on how to create your own “Dockerfile for systemd base image” on their dockerhub readme: https://hub.docker.com/_/centos/ ]

my concern is, that without such hoop jumping, native, installed packages that try to install/enable their /etc/init or systemd unit files or /etc/init.d files are going to behave differently than real systems running on the exact same OS.

not to mention the OSX support for running systemd is missing (it requires --cap-add=SYS_ADMIN, apparently only on OSX, to allow systemd to mount tmpfs) cf. https://github.com/moby/moby/issues/30723

is the requirement to use systemd inside of docker or to use systemd to start containers (e.g. like in CoreOS)?

actually, i’m not quite clear on the problem statement.

goal I’m trying to work with is that packer treats a docker builder the same as an EC2 builder… assuming they both start with the same OS image…. that systems work as similarly as possible.

aha, i see

@catdevman does this sound familiar?

@catdevman was telling me yesterday that they use packer to build both their AMIs and docker images and using Amazon Linux as base for both.

thats where I’d like to be

Thanks Erik. That sounds close. @catdevman when you have a moment, I’m interested to hear your strategy for using packer to create both docker images and AMIs

fwiw, when we’ve needed init in containers we’ve used s6 or dumb-init

https://skarnet.org/software/s6/

The folks at Yelp are

yeah @tamsky I can share some of that information… the biggest part is that your starting point has to be the same so for us we went with amazon linux and ubuntu. Only problem with this strategy is docker and assuming everything is root and doesn’t have sudo which means become for ansible needs to be variable and needs to know what type of build you are doing.

@tamsky I have made separate packer files for ami and docker but the ansible playbooks are the same just different variables passed in. if you want to know more we can do pm

Thanks @catdevman, that lines up 100% with my starting points (amazonlinux:2, ubuntu:18.04) and matches where I’m at with packer+ansible. I’d be interested to share my docker bits and ansible “hacks” that I’m using to remove the differences between container and AMI.

maybe we should have a #ansible channel? @Erik Osterman (Cloud Posse)

@tamsky sure thing!

I will create in a few

Hello people! Any recommendations for a a docker centric CI that just builds and uploads images, and utilizes caching

because I am losing my s*** with travis ci

travis cannot into Docker

we use https://codefresh.io/

ahha I knew it !

all pipeline steps are containers

soo I was checking out the pricing, and 3 concurent builds which is the pro subscription won’t do

any idea how will it cost to have let’s say 20 concurent builds ?

you need to discuss that with @Erik Osterman (Cloud Posse), he can provide more info and connect you with the Codefresh guys

(Y)

Thanks

one example how we use our Docker images in Codefresh pipelines https://github.com/cloudposse/github-status-updater#integrating-with-codefresh-cicd-pipelines

thanks @Andriy Knysh (Cloud Posse)

set the channel topic:

I just found this today: https://github.com/just-containers/s6-overlay interesting approach vs trying to support multiple flavors of init(1) within docker: sysv, upstart, systemd

That’s cool!