
What’s New in Docker 1.13? - hackerpt
https://blog.docker.com/2017/01/whats-new-in-docker-1-13/
======
iends
Docker for Mac is a pretty terrible experience.
[https://github.com/docker/for-mac/issues/77](https://github.com/docker/for-
mac/issues/77) has eaten a huge chunk of time for my team and the issue has
been open and known about since the beta. Yes there are hacks to make things
better, but as of a month or two ago the Docker team seems to have gone radio
silent after providing periodic updates.

~~~
duncan-donuts
I have given up on using docker on macOS. I now use Ubuntu at work, and it's
interesting to watch a lot of my co-workers give up on macOS too. I totally
agree it is a horrible experience.

~~~
dandermotj
Use Docker on Ubuntu on my own machine, but forced to use a Docker on Windows
at work. Using Docker on Linux is an absolute joy. I totally advocate it.
Dockerhub is my first port of call when I'm installing something new on my
machine because I know if there's an official repo it will work.

Docker outside of Linux is another story. I've run into config issues, VM
memory problems, proxy issues, ect. Painful.

~~~
duncan-donuts
Same here. I was struggling using docker at work on my Mac, but when I was
working at home on my Linux box it was amazing. Docker is awesome on Linux and
I have never been more productive.

------
jzelinskie
Hopefully native squashing will allow some people to avoid writing Dockerfiles
that look like

    
    
      RUN this && that && thistoo && thattoo && rm this && rm that
    

in order to avoid generating extraneous layers.

There have been some third party tools and registries that implement this
feature, but it's nice to finally have it upstream.

~~~
donw
Honestly, I see this as an antipattern, not because it generates extra layers,
but because a Dockerfile isn't the right place to write a provisioning script.

When building apps, I keep a small number of shell scripts that live in a
`bin` directory, that perform essential operational tasks.

One script installs all the dependencies required to either run or develop the
app; another runs all tests and exits with either success or failure; and the
final script just runs the app.

Docker then just runs those scripts, which are written deliberately to be
easily read, and thus function as living documentation for the project.

These same scripts get used, both by developers on a daily basis, as well as
by our CI/CD system when prepping containers.

This also makes onboarding a snap: you run `bin/setup`, and your Mac or Linux
box is good to go. And, because that script gets used every time the CI system
spins up a build, it will never go out of sync with reality.

~~~
yladiz
The problem is that if you're building images a lot, Docker doesn't cache COPY
calls because it doesn't know if the file has changed or not when calling the
COPY command. So if you constantly build images and there are a lot of
computationally intensive tasks within those scripts, but you've only changed
one small item near the end of the script, your build time may be
significantly longer by using the script than by putting it directly in the
Dockerfile using the RUN command.

I build a lot of modules within one of my Docker images for work, and while it
doesn't change often, I would really not like to wait the 20 minutes if I
really needed to push to production when I only change some certificate
population segment at the end of the Dockerfile or something after a
particularly intensive module build RUN step.

~~~
shawabawa3
Docker does cache COPY calls AFAIK.

If you're copying your whole directory though the cache breaks if any file
changes.

The normal way of doing it is to copy stuff like requirements.txt,
package.json, Gemfile etc first and install stuff, then copy everything else
at the end

~~~
yladiz
Ah, maybe that's true, I always figured it didn't cache it since it wasn't
text. In this case it doesn't matter since the script would change, but if the
scripts were broken apart and ran using RUN commands it would be a better
middle-ground solution than wholly putting it all in a script with a single
RUN command.

------
chrisfosterelli
I'm very excited about the clean-up commands!

Docker _desperately_ needs this, it's so frustrating constantly having full
disk space due to untagged containers and unbounded volumes.

~~~
geerlingguy
If you're on Mac, it's still a bit of a problem; hopefully the SSD-gobbling
Docker.qcow2 file problem[1] is fixed soon!

[1] [https://github.com/docker/for-
mac/issues/371](https://github.com/docker/for-mac/issues/371)

~~~
selvakn
Looks like it is fixed in
[https://twitter.com/kelseyhightower/status/82223709949555097...](https://twitter.com/kelseyhightower/status/822237099495550976).
Im looking for official changelog for confirmation though.

~~~
iends
Judging by the github issue list there are a lot more issues with Docker.qcow2
now than before. Mostly related to Docker.qcow2 preventing docker from
starting.

Looks like a bad release. Hopefully 1.13.1 is soon.

~~~
djs55
(I work on Docker for Mac.)

Apologies for the inconvenience this has caused.

There was a race condition in a previous release which could allow multiple
hypervisor instances to open the Docker.qcow2 simultaneously. Unfortunately
this can corrupt the file by allocating the same physical block (cluster)
twice, resulting in bad things happening. When this file-locking bug was fixed
we also added an integrity check which checks the structure of the
Docker.qcow2 on every application launch. For safety the app refuses to start
if corruption is detected.

I believe that in these cases, the corruption happened in the past and is now
being detected since the upgrade. Unfortunately if the app refuses to start it
makes it difficult to reach the "Reset to Factory defaults" menu option. The
workaround described here [https://github.com/docker/for-
mac/issues/1159#issuecomment-2...](https://github.com/docker/for-
mac/issues/1159#issuecomment-273899215) is to remove the qcow2 and restart the
app. Unfortunately containers and images will need to be rebuilt.

For what it's worth after the integrity check and the locking fix went in,
I've not seen any recurrence of this error. Please open an issue if you see
any other problems!

------
dchuk
The "Use compose-files to deploy swarm mode services" is really intriguing to
me, especially when they quote this one liner:

> docker stack deploy --compose-file=docker-compose.yml my_stack

But there's no links to further documentation or anything. Can this be used to
deploy easily to a cluster of Droplets for instance?

I feel like the low end/longtail deployment of Docker is really underserved. I
want to use Docker for its devops merits, but I have yet to find a clear,
concise guide for deploying a simple web app to one or a cluster of VPS
instances for a modest traffic project.

~~~
andrewstuart2
Have you looked at Kubernetes? It's pretty dead simple to get a cluster up
these days and the general abstractions they chose are really great. Service
discovery, config and secret storage, control loops, autoscaling, even
stateful containers these days.

100% worth giving it a shot, even just to say you've tried it.

I've been using Docker for over three years now, and Kubernetes really is the
realization of what I imagined containers would be like when I was just
starting to use them in development.

~~~
ekidd
> It's pretty dead simple to get a cluster up these days

The standard Kubernetes setup instructions are horrible. You need to run a
bunch of shell scripts including cluster/kube-up.sh, which are documented to
work on AWS, but which are completely untested before release, and which were
recently broken for almost a month.

I'm currently running Kubernetes under Rancher. It's still a pretty steep
learning curve, with some very well-hidden but essential configuration
parameters, but at least it actually works if you follow the instructions.

~~~
lentil
The situation has been improved quite a bit with kubeadm. Getting a basic
cluster set up is a lot easier with that.

[https://kubernetes.io/docs/getting-started-
guides/kubeadm/](https://kubernetes.io/docs/getting-started-guides/kubeadm/)

------
colemorrison
In addition to crappy mounted volumes, Docker for Mac eats up CPU like crazy:
[https://forums.docker.com/t/com-docker-hyperkit-up-cpu-
to-34...](https://forums.docker.com/t/com-docker-hyperkit-up-cpu-
to-340/13057/2)

And, also like the mounted voluems issue, despite this being on of the top
things on the forum, it's still been a problem for like 8 months with no
attention.

------
HorizonXP
This release broke our Azure Container Service Kubernetes deployment. Had to
downgrade back to 1.12 for now, but not without suffering a day of downtime
trying to trace the issue.

~~~
tristanz
What was the issue?

~~~
HorizonXP
[https://github.com/Azure/ACS/issues/3](https://github.com/Azure/ACS/issues/3)

------
tvaughan
Use Terraform to provision some virtual machines, load balancers, bastion
host, vpc, etc.
[https://news.ycombinator.com/item?id=13436415](https://news.ycombinator.com/item?id=13436415)

Use Docker to setup development and production environments for a sample Flask
application with CI/CD.
[https://news.ycombinator.com/item?id=13436452](https://news.ycombinator.com/item?id=13436452)

------
jstoja
Huge news, I really hope this is gonna help the workflow and give another
alternative for scheduling. I have been waiting for the update since last
November (iirc it was scheduled for end of 2016).

BTW - Am I the only one finding the quality of the linked video very bad?

------
LeonM
> docker system df will show used space, similar to the unix tool df

I thought 'df' is for free space, 'du' is for used space. Can anyone explain
why the went for 'df', not 'du'?

~~~
legooolas
df shows both used and available space on a whole disk/device.

du is for space used by particular files/directories.

------
jstoja
I can't find anything about secrets in compose files... Any ideas about this?

~~~
jstoja
Ok, it still seem to be in development:
[https://github.com/docker/docker/pull/30144](https://github.com/docker/docker/pull/30144)

------
LeanderK
why does the squash flag squash everything? Wouldn't it possible to only
squash the layers introduces in the localhost build? The you could share the
other layers again.

~~~
cpuguy83
It only squashes the layers produced by the build.

------
unixhero
I moved on to LXC

Never looked back

Congrats to the docker team in the new release anyhow.

~~~
theamk
What do you use instead of "docker build" and "docker pull"?

~~~
jryan49
Could use the distro's package manager?

~~~
theamk
What do you mean? My Dockerfiles already use distro's package manager to
install packages.

Do you you mean "create a long-lived LXC container and use distro's package
manager to install packages as needed?" The problem with that approach is you
have no idea how to duplicate the server, nor how to roll back the changes
reliably. For example:

\- Your distro upgraded a library, and the upgrade introduced a bug. For extra
fun, this was not security upgrade so unattended-upgrade process did not
install it, so only half of your servers have the bug.

\- Your package list is incorrect. Somehow, your old server ended up with an
extra package (previous software version? installed while trying to
troubleshoot problems), and your new server does not have it.

\- You have leftover files -- either from the previous version of your
software, or from the package you have had installed before.

These are definitely fixable in LXC with enough effort -- after all, Docker is
not magic, and you can achieve a lot with LXC + shell scripts, and even more
with LXC + shell scripts + chef. However, Docker is just so much easier and
reliable than writing these scripts by hand.

~~~
unixhero
LXC is sane to me. Upon first glance it is understandable and works everytime.

I went all in with Docker, it was all fun and games up until I tried it in
production, and I started relying heavily on it.

Docker introduces container linking voodoo which have burnt me badly. Sure
enough voodoo comes with its upsides, we now have Kubernetes which obviously I
think is very cool. Just far outside of my use case.

Serenity now!

