lab2 comments

[langdon]

I forgot the nice note at the top of these comments, but, here is the branch: https://github.com/whitel/summit-2015-lab-15812/blob/ldw-lab2-comments/labs/chapter2.md

HASH SO... i made some edits to content, also asked some questions in this very annoying, but, easily removable, way :)

[dustymabe]

langdon: why? you are clearly implying monolithic is icky.. so why are we teaching them it? well, i would say, because it is "fine" for your first cut of an existing app in containers (or something)

How about: Typically it is best to break down containers into the simplest components and then use each of them independently. In this lab we will do exactly the opposite. We will create an all-in-one container image comprised of multiple services as well as observe several bad practices when composing Dockerfiles and explore how to avoid those mistakes. In the lab3 we will decompose the application into more manageable pieces.

langdon: ^^^ see https://github.com/whitel/summit-2015-lab-15812/issues/33

I asked a question in the issue. Will update once we have resolution.

langdon: worth explaining why 1) you can use "bigapp" instead of container-id? 2) it is "bigapp" and not "monolithic"?

monolithic is the name of the docker image. perhaps I can rename that to bigimg instead. I will update and also explain why we can use "bigapp" instead of container id

langdon: how do i know what the ip is?

I'll add notes on how to find the ip.

langdon: do we have any tools that would point out these issues?!?!? :)

I've honestly never used the linter. Should we simply give it a mention here or should we actually try to use it?

[dustymabe]

I addressed some of these comments in ac5c6da.

[langdon]

@aweiteka linter? (see dusty's question above)

@dustymabe "single container vs multi" "Typically it is best to break down containers into the simplest components and then use each of them independently. In this lab we will do exactly the opposite. We will create an all-in-one container image comprised of multiple services as well as observe several bad practices when composing Dockerfiles and explore how to avoid those mistakes. In the lab3 we will decompose the application into more manageable pieces."

So, i think the above is good.. but, i think what we are also trying to show in the lab is that sometimes (with existing applications), it is easier to move the whole thing in to a container, then break out the services in to their own containers over time. Running your app as one big container will give you some benefits of containerization in the near term and, as you work through decomposing the application in to multiple containers, you will identify and fix issues with your application that you may not have even known you had regarding horizontal scalibilty. In other words, following the lab2->3->4 approach with an existing application allows you to approach the problem in parts without having to do a massive re-architecture, with its associated risk(s) and cost.

[langdon]

@dustymabe also, I would merge in your changes to the content, i read through them.

[dustymabe]

Good point.. I'll try to add some wording to that effect.