
Learn Docker by building a Microservice - sidcool
http://www.dwmkerr.com/learn-docker-by-building-a-microservice/
======
WestCoastJustin
This is a very good tutorial! Love the end-to-end examples. Great teaching
method as it gives an overview of what you want to achieve without looking at
things in isolation. Wanted to add one bit of info and give a heads up about
the Docker for Mac & Windows beta at
[https://beta.docker.com/](https://beta.docker.com/).

> _If you are on Mac or Windows, consider using a Virtual Machine. I use
> Parallels on Mac OS X to run an Ubuntu machine for most development
> activities. Being able to take snapshots, break things and then revert back
> is very handy when experimenting._

The beta will make is super easy to use Docker on Mac & Windows without
running a heavy Virtual Machine. Here's a little video about it @
[https://blog.docker.com/2016/03/docker-for-mac-windows-
beta/](https://blog.docker.com/2016/03/docker-for-mac-windows-beta/).
Basically, it feels like running Docker natively, has upgrade features build
it, so you can choose to always be on the latest release (super nice). I've
been using it for a few months and it is awesome to just type "docker run" on
my macbook and have it work seamlessly (vs using third party virtual machine
software and env bits). The idea is that you can develop on Mac & Windows
using the same images you will eventually deploy. It just works (although I'm
biased).

Disclaimer: Work for Docker.

~~~
0942v8653
When signing up for the beta, there is a required Company field; what do I put
there if I am a student?

~~~
WestCoastJustin
I'd just put "N/A" or "Student". I'll check about this internally too. Thanks
for the heads up.

------
Cyph0n
Excellent tutorial! I'm a newcomer to Docker, and this was quite helpful. I'm
currently using Vagrant to run my local dev environment and it's been OK. But
I can see how using containers to split components up can make testing much
easier.

One question I have though is how useful is Docker for deploying production
applications?

Firstly, can plain Docker be used for the whole setup or is something like
Kubernetes required to tie the containers together?

Secondly, is there a performance hit when you use multiple Docker containers
on the same server? Or should it be a one-to-one relation i.e. one container
per as server? If so, why not just use plain servers with Chef or Puppet for
server management?

These questions are assuming that I'm using my own servers - something like
DigitalOcean or AWS. I'm not a huge fan of managed container services; it
feels like there's too much "magic" going on behind the scenes.

~~~
cromantin
I highly recommend looking at rancher. It's great in every way.

~~~
iyn
How does it compare/relate to Deis Workflow (used to be called v2;
[https://deis.com/](https://deis.com/))?

~~~
lobster_johnson
I would say it goes: Deis > Rancher > Docker.

Rancher is an orchestrator built on Docker. It handles scheduling of
containers and certain auxilary objects (load balancers, for example) within
that universe. Rancher builds on the Docker Engine and can integrate with
things like Mesos and Kubernetes, but doesn't require anything else to get up
and running; it comes with its own container scheduler.

Deis is an entire PaaS, designed to handle end-to-end deployment and hosting
of apps. It requires Kubernetes to run, which is notoriously complex (even on
Google's Cloud) and probably not worth the effort if you have a small number
(some people say >10) machines.

~~~
iyn
Thank you, you really clarified my view on these tools. I don't have
experience with K8 and GCE, but when it comes to AWS, it doesn't seem so
complex: [http://kubernetes.io/docs/getting-started-
guides/aws/](http://kubernetes.io/docs/getting-started-guides/aws/) but I
don't have production experience with this setup either, so who knows ;).

~~~
lobster_johnson
Kubernetes _is_ complex — no matter where you run it. Docker itself is also
complex; any orchestration/scheduling system layered on top of it will by
definition add a dynamism that involves complicated things happening whenever
something needs to be shuffled around.

Kubernetes makes some good design decisions. For example, you can kill the
master and the cluster will continue to work just fine, except no scheduling
will happen. You get some operational simplicity through how Kubernetes
dedicates an IP to each container, too. Several other systems (including
Rancher) make the mistake of relying on DNS to abstract the locations of
services from clients, but Kubernetes dedicates a single, permanent IP to each
service, which is then routed it at the network level. (In case you're
curious, DNS is a huge mistake because it's almost never used correctly [1],
and there are numerous Rancher issues filed that all stem from this design
flaw.)

I wouldn't consider Kubernetes for simple setups, even on GCE, where it's
"managed". (Scarequotes because GCE starts a master for you from a prebuilt VM
image, but everything else is up to you; the only real UI is the standard one
the master runs.) For smaller setups, you might want to consider a simpler
solution such as Docker Compose, Docker Swarm or (once it's mature enough)
Nomad.

Rancher is nice, but IMHO not ready for prdoctuon; it's much too unstable for
an 1.0 release. I set it up to test recently, and within a few minutes I had
encountered several serious bugs and several design flaws, including the fact
that Rancher's load balancer (which is just HAProxy) loses traffic whenever
it's reconfigured.

AWS has the EC2 Container Service (ECS), which is essentially a proprietary
Docker scheduler that AWS preinstalls on your VMs. The consensus seems to be
that it's one of Amazon's worst products, which my own brief attempt at
playing with it confirmed.

Sorry about the long-winded reply, it got out of hand. :-)

[1] [http://nerds.airbnb.com/smartstack-service-discovery-
cloud/](http://nerds.airbnb.com/smartstack-service-discovery-cloud/)

------
krat0sprakhar
Awesome tutorial! Love the deep dive into building the entire service and
using compose to get it running. If you're interested in how to deploy your
docker apps online, I wrote a tutorial which some of you might find useful -
[http://prakhar.me/docker-curriculum/](http://prakhar.me/docker-curriculum/)

------
n_coats
Great post!

For those learning, make sure you look into removing unused images and
containers otherwise you might run into some issues a little farther down the
road (eventually our builds started failing).

You can run docker rm and docker rmi to remove specific containers and images
respectively, but we also found passing the --rm flag with docker run helped a
lot as it removes a container after it exits.

Happy learning!

~~~
ThunderGorilla
Why did this cause the builds to fail?

~~~
beardicus
Presumably because they ran out of space on the host that was doing the
building. It's very easy to never see the gobs of containers and images no
longer in use with docker.

~~~
n_coats
Exactly what happened.

------
benmarks
Is there some standard architecture illustration tool for Docker? The graphic
from this post is quite similar to the one from last October at
[http://www.teckstory.com/hadoop-infrastructure/docker-
tutori...](http://www.teckstory.com/hadoop-infrastructure/docker-tutorial-for-
beginners/) \- [http://www.teckstory.com/wp-
content/uploads/2015/10/Docker-A...](http://www.teckstory.com/wp-
content/uploads/2015/10/Docker-Architecture.png)

------
koolba
> What you are seeing is the bash shell of an isolated container running
> Ubuntu, on your machine. It's yours to place with - you can install things
> on it, run software, whatever you want.

Nitpicking a bit on security, but root in a container is still root on the
host right?

~~~
falcolas
Yes. You're depending on the isolation provided by the cgroups to keep root
inside it's cage. It's one reason there was a problem a year or so ago with
root users inside a container being able to access the kernel keyring for
processes outside the container.

~~~
davexunit
cgroups do not provide isolation, namespaces and chroot do.

------
neo1691
This is a pretty amazing tutorial on docker. I was always confused with the
difference between docker and virtual machines. This makes more sense now.

------
pawadu
Are there any similar tutorials for LXD?

------
mdk754
> We might not want to run our production database in Docker (perhaps we'll
> just use Amazon RDS for example), but we can spin up a clean MySQL database
> in no time as a Docker container for development - leaving our development
> machine clean and keeping everything we do controlled and repeatable.

Curious why you wouldn't want to run it in docker in production? Wouldn't
running the same container in dev/prod be helpful?

~~~
tayo42
What is there to gain by putting your database in a container? A database
probably has its own dedicated server so, your probably not deploying
databases often and there's the added complexity of making your data
persistent.

~~~
mdk754
Your point stands, and obviously makes more sense.

My curiosity was more in whether there were performance (or other) bottlenecks
which made it technically infeasible.

------
josh_carterPDX
So cool. I knew a bit about Docker, but after running through this tutorial
I'm already licking my chops at what else I can learn. More please! :)

------
olau
Does anyway know if there's an easy to encrypt a docker volume in a dev
environment?

So basically, I'd start a docker database container, it'd ask for a password
and then decrypt and start the container and the database. When I shut down
the machine and leave the office, I can then be sure the data in the container
isn't readily available if someone breaks in a take the computer.

------
azimuth11
Nice tutorial!

For those following along, I've noticed a few errors/typos, and maybe others
in the thread caught them...

* Container ports are exposed like so, HOST_PORT:CONTAINER_PORT, or YOUR_MACHINE:DOCKER_VM. If you already have a mysqld instance running, then try using 3308:3306

* The /search route needs a "next" parameter in users.js:

"app.get('/search', (req, res, next) => {"

------
alistproducer2
I've been using docker for a couple months but I still learned some new stuff.
Awesome tutorial! Docker should be required learning in any CS program. I
cannot fathom why anyone would setup environments any other way.

~~~
pawadu
Do you think CS programs should teach someframework.js too?

Where is the Science in using stuff other people have put together (and then
written a detailed instruction on how to use it)?

~~~
alistproducer2
Serious question: have you been through a CS program? In addition to the
mathematical and theoretical underpinnings of the discipline, a large part of
what is taught is how to engineer software. IMO Docker is a major step forward
in software engineering, this is why I believe it should be taught.

~~~
davexunit
>IMO Docker is a major step forward in software engineering

And a lot of people, myself included, disagree. Docker is a huge step
backwards because it is covering up the major underlying issues of package
management. It's a sledgehammer solution to a problem for which more
composable, elegant solutions exist.

------
Annatar
Wow, I read that article and it just made me cringe every step of the way.

What could have been:

    
    
      # imgadm install image-uuid
      # vmadm create -f vm.json

[1][2] ...instead is a whole bunch of hacking on a whole bunch of things...
One would think that with as much as SmartOS has been discussed here on Hacker
News, people would finally realize there is something simpler out there
without all this pain, but apparently not. Crazy!

[1]
[https://wiki.smartos.org/display/DOC/Managing+Images#Managin...](https://wiki.smartos.org/display/DOC/Managing+Images#ManagingImages-
ImportingImagesLocally)

[2]
[https://wiki.smartos.org/display/DOC/Using+vmadm+to+manage+v...](https://wiki.smartos.org/display/DOC/Using+vmadm+to+manage+virtual+machines#Usingvmadmtomanagevirtualmachines-
CreatinganewVM)

~~~
justinsaccount
Smartos is neat. I run smartos at home.

Let me tell you, you are not doing smartos any favors.

People don't give a shit about how great you think smartos is. "smartos can do
this", "smartos can do that". blah blah blah.

Do you know what the difference is between the posted link and your comments?
The stuff in the article actually works, while your "look how simple it is"
comment, does not:

    
    
      [root@srv2 ~]# uname -a
      SunOS srv2 5.11 joyent_20160504T205801Z i86pc i386 i86pc
      [root@srv2 ~]# imgadm install image-uuid
      imgadm install: error (Usage): unexpected args (1): "image-uuid"
      [root@srv2 ~]# vmadm create -f vm.json
      File: vm.json does not exist.
    
    

Compared to the process outlined in the article that works, and shows you how
to setup the entire process to, build, rebuild, and run two separate
containers.

Their first command is basically

    
    
      $ docker run -it --rm ubuntu  
      root@37ffd019060f:/#
    

Which anyone with docker installed can run. Your first command returns an
error message.

And then you go on to say

> With SmartOS, the database image can be preconfigured and published into the
> catalog

> one XML file and svcadm import later, the thing is ready to be turned into
> an image, never to have to be revisited again

> a single invocation of vmadm -f vm_definition.json

So all you have to do is preconfigure things (how?), publish them into the
catalog (whatever that is) and write both an xml and a json file (contents
unknown) to start your service.

If you actually cared about getting people interested in smartos, you would
write a "learn-smartos-by-building-a-microservice" article and show how to
actually use the fucking thing instead of ranting how terrible docker is.

~~~
Annatar
> Do you know what the difference is between the posted link and your
> comments? The stuff in the article actually works, while your "look how
> simple it is" comment, does not:

The usage I provided is a SYNOPSIS, as in synopsis from a manual page. You
will note that mine is a comment, not an entire blog article (I do not have a
blog).

The intent behind my comment is to provide a pointer to further exploration;
it is not a how to document, but rather a starting point for those who are
actually willing and able to sit down and read some documentation, which is in
the links I provided, and will provide the equivalent of what the author's
article does, and dividends on top of that. (Less incidents in the dead of the
night equals long term dividends.) My intent was that someone will read it and
go off to explore it.

That is not to say that I do not agree with your point, as I myself am a firm
believer in examples which work. However, one must at some point have the
experience to distinguish between a synopsis and a guide. A lone comment on
Hacker News is not the place for an entire how to guide.

> Which anyone with docker installed can run.

Yes, but as with anything, there will be long term consequences: while anyone
can get it up and running easily, when it comes time to put it in production,
and the thing busts because there is no lifecycle management, no change
management, no configuration management (sorry: dumping a bunch of files into
a Docker "image" definition doesn't even come close to lifecycle management,
or capability maturity model level 2[1]), no post mortem debugging facilities,
no end-to-end data integrity, and performance penalty for running inside of a
fully virtualized VM, the problems will start.

For example, MySQL was also "easy to set up", but that didn't change the fact
that the software does not work correctly[2] and that MySQL deployments later
caused many organizations many problems. Just because something is easy to set
up does not mean it is a good solution to deploy. Nowadays people are
realizing that and migrating to PostgreSQL because that software does work
correctly, but all that time, effort and money spent because of how "easy"
MySQL was to get going could have been prevented in the first place. With
Docker and how it is designed, and based on what I know, I can see the same
types of problems which will inevitably lead to outages. And in the interest
of disclosure, what is it to me? Well, argumentum ad populum is extremely
spread these days, which means that lots of jobs would (and have) started
springing up with Docker, which means I would be forced to work with what I
know from experience is inferior technology. Since I see the problems of
Docker, that means I would not be able to sleep through the night, and spend
my nights in conference calls with clueless managers demanding that I fix it.
I do not want that; I want to sleep through my nights, and work with slick and
reliable technology like SmartOS, not a toy like Docker causing me problems
down the road, and just because it was popular.

You are making an indirect argumentum ad populum, which is never a good thing.

> If you actually cared about getting people interested in smartos, you would
> write a "learn-smartos-by-building-a-microservice" article and show how to
> actually use the fucking thing instead of ranting how terrible docker is.

If you had bothered to read the documentation in the links, you would have a
pretty good idea on "how the fucking thing works", and how to build a
microservice; I am sorry if you think that clicking on the links and reading
through the articles is too much overhead. How is it then, that reading
through that Docker article isn't overhead, and you had no problem clicking at
that?

[1]
[https://en.wikipedia.org/wiki/Capability_Maturity_Model#Leve...](https://en.wikipedia.org/wiki/Capability_Maturity_Model#Levels)

[2]
[https://www.youtube.com/watch?v=emgJtr9tIME](https://www.youtube.com/watch?v=emgJtr9tIME)

