5 ms·

You missed the bigger point. Just look at the popular images on Docker hub. A lot of them involve messy build steps, including downloading binaries or source

You missed the bigger point. Just look at the popular images on Docker hub. A lot of them involve messy build steps, including downloading binaries or source tarballs without verification. It's often hard to know which dependencies a Docker image has, and therefore hard to track vulnerabilities and redeploy fixed images. A lot of docker containers end up either running for a long time, or get rebuilt and redeployed often, but have pinned versions of base images or dependencies which still leaves vulnerabilities in place. This is compensated a bit by the fact that Docker does provide somewhat decent isolation, and most containers are run in a cloud environment, behind load balancers and with decent security constraints. But there are many pitfalls in the whole process. Containers provide a lot of advantages, and are certainly where things will continue to go. But we need to figure out the tooling and ecosystem story to build, verify and update container deployments securely.

Annatar 7y ago
"But we need to figure out the tooling and ecosystem story to build, verify and update container deployments securely." Already done: Solaris zones. Available in the SmartOS distribution near you. Combine with OS packaging, imgadm and vmadm commands for maximum impact.
- regularfry 7y ago
  I suspect there's a similar story around LXC available.
  - deleted 7y ago
    [deleted]
- ti_ranger 7y ago
  I've spend 1 minute skimming some of the docs, but it's unclear whether these tools can do a better job than the docker-like tooling. The vmadm "build an image from scratch with a json file" doesn't help in building Hadoop any more than the oldest versions of docker did using a minimal image and a Dockerfile. How does provide visibility into every dependency inside an image? Especially when using 3rd-party-maintained images that consist of significant hours of work per image to get the image to work. (BTW., I built "live CD images" for use in physical and virtual machines since ~2001, using tools such as mklivecd, livecd-tools etc.).
  - justinsaccount 7y ago
    It doesn't. He's a troll that claims solaris is the solution to every problem that he doesn't understand.
oauea 7y ago
Just build your own. It's not that hard. Before containers we would script the install process using Ansible. With containers we script the install process using a Dockerfile. If you know how to do one, you know how to do the other. Just don't be lazy and use unofficial images created by people you don't know or trust. Just like you wouldn't pull any random role from ansible-galaxy. Or pull a random guy off the street and ask them to provision your infrastructure for you. Then all you have to do is just rebuild your images every week and you're set. All we had to do for this was have our Jenkins build pipeline run weekly & have it pass `--pull --no-cache` to `docker build`.
- mkesper 7y ago
  You can even avoid dockerfiles by using Ansible: https://docs.ansible.com/ansible/latest/scenario_guides/guide_docker.html https://docs.ansible.com/ansible/latest/scenario_guides/guid...
  - oauea 7y ago
    We tried that about a year or two ago with `ansible-docker`. At the time it didn't leverage the docker cache so it was quite slow. Looks like that got replaced with `ansible-bender` which according to the readme does use the docker cache! Thanks for mentioning this, will definitely have to give this another go.
GordonS 7y ago
> A lot of them involve messy build steps, including downloading binaries or source tarballs without verification Do they though? Whenever I write Dockerfiles that depend on external downloads, I always check the hash matches one baked into the Dockerfile itself, and I've always seen others doing the same.
- takeda 7y ago
  I have seen this many times, generally the high profile containers do that, and these issues are more common among my peers. This requires self discipline and containers were pushed as a panacea for environments where the discipline is lacking.
  - gmueckl 7y ago
    What is the point of storing the hash of an external file instead of checking the file into local version control? You're making it a part of your sources either way.
    - takeda 7y ago
      People who want to run docker don't want to run artifactory. I'm not saying it's a good thing, but that's what I observed.
  - GordonS 7y ago
    Do you have any examples of high-profile images that do this? I really just haven't seen this with the ones I use.
    - takeda 7y ago
      Sorry, I see that my response looks ambiguous. I meant the opposite. The high profile containers generally do the right thing, but containers created by peers rarely do it. There's no mechanism to make things reproducible you need to implement it yourself, and from my experience most people (not the ones that release something publicly, but ones that work for a companies that use it) don't do it.

Annatar 7y ago

"But we need to figure out the tooling and ecosystem story to build, verify and update container deployments securely." Already done: Solaris zones. Available in the SmartOS distribution near you. Combine with OS packaging, imgadm and vmadm commands for maximum impact.

regularfry 7y ago
I suspect there's a similar story around LXC available.
- deleted 7y ago
  [deleted]
ti_ranger 7y ago
I've spend 1 minute skimming some of the docs, but it's unclear whether these tools can do a better job than the docker-like tooling. The vmadm "build an image from scratch with a json file" doesn't help in building Hadoop any more than the oldest versions of docker did using a minimal image and a Dockerfile. How does provide visibility into every dependency inside an image? Especially when using 3rd-party-maintained images that consist of significant hours of work per image to get the image to work. (BTW., I built "live CD images" for use in physical and virtual machines since ~2001, using tools such as mklivecd, livecd-tools etc.).
- justinsaccount 7y ago
  It doesn't. He's a troll that claims solaris is the solution to every problem that he doesn't understand.

oauea 7y ago

Just build your own. It's not that hard. Before containers we would script the install process using Ansible. With containers we script the install process using a Dockerfile. If you know how to do one, you know how to do the other. Just don't be lazy and use unofficial images created by people you don't know or trust. Just like you wouldn't pull any random role from ansible-galaxy. Or pull a random guy off the street and ask them to provision your infrastructure for you. Then all you have to do is just rebuild your images every week and you're set. All we had to do for this was have our Jenkins build pipeline run weekly & have it pass `--pull --no-cache` to `docker build`.

mkesper 7y ago
You can even avoid dockerfiles by using Ansible: https://docs.ansible.com/ansible/latest/scenario_guides/guide_docker.html https://docs.ansible.com/ansible/latest/scenario_guides/guid...
- oauea 7y ago
  We tried that about a year or two ago with `ansible-docker`. At the time it didn't leverage the docker cache so it was quite slow. Looks like that got replaced with `ansible-bender` which according to the readme does use the docker cache! Thanks for mentioning this, will definitely have to give this another go.

GordonS 7y ago

> A lot of them involve messy build steps, including downloading binaries or source tarballs without verification Do they though? Whenever I write Dockerfiles that depend on external downloads, I always check the hash matches one baked into the Dockerfile itself, and I've always seen others doing the same.

takeda 7y ago
I have seen this many times, generally the high profile containers do that, and these issues are more common among my peers. This requires self discipline and containers were pushed as a panacea for environments where the discipline is lacking.
- gmueckl 7y ago
  What is the point of storing the hash of an external file instead of checking the file into local version control? You're making it a part of your sources either way.
  - takeda 7y ago
    People who want to run docker don't want to run artifactory. I'm not saying it's a good thing, but that's what I observed.
- GordonS 7y ago
  Do you have any examples of high-profile images that do this? I really just haven't seen this with the ones I use.
  - takeda 7y ago
    Sorry, I see that my response looks ambiguous. I meant the opposite. The high profile containers generally do the right thing, but containers created by peers rarely do it. There's no mechanism to make things reproducible you need to implement it yourself, and from my experience most people (not the ones that release something publicly, but ones that work for a companies that use it) don't do it.