6 ms·

> if I'm deploying to Swarm, do I use Machine or Compose? All three actually seem to work quite nicely together[0] [0]: https://blog.docker.com/2015/02/orche

by numo16 11y ago

> if I'm deploying to Swarm, do I use Machine or Compose? All three actually seem to work quite nicely together[0] [0]: https://blog.docker.com/2015/02/orchestrating-docker-with-machine-swarm-and-compose/ https://blog.docker.com/2015/02/orchestrating-docker-with-ma...

mpdehaan2 11y ago
Yeah, I read that back in the day, and I'm still finding it hard to follow. I'm trying to pass on some marketing advice here mostly. Leaving it to the reader to try to assemble a video down into their brains, because they have problems with the text wall (particularly visual learners) is probably not a good thing. I work best off examples and pictures. I'd benefit hugely by having a list of the CLI commands, without the text filler, showing a few use cases end to end. I have a hard time keeping all the video in my brain all at once. Just seeing the bash history alone, with some light text commentary, would work for me better than the video -- by a lot. I know different people learn differently. Show all three tools delivering a "pet store" type stack maybe. Tell me when do I want compose and when can I skip it, as quickly as possible. I know these are things you can figure out in several hours/days by trying them all, but for those of us that don't have time, it needs to be presented at a higher level showing how they connect, rather than the marketing speak "it works great together" and then pages that contradict that by saying the integration is minimal. The current result is everyone's Docker topology is VERY different. I know it's not proscriptive, but it's a bit of a mess. I've encountered a lot of people doing lightweight cloud with Docker (basically no-cloud) with Ansible and manual instance management, for instance, and there SHOULD be better options - but I think people go that route because they are confused about the complexity of options they have. Back down to technical bits, I see the line "we're working with AWS to make Swarm usable on ECS", etc, as confusing and a bit marketey (as to the reason for the integration). Why do I need Swarm on ECS? Make the case, etc, these already appear to be container orchestrators. What does Swarm add on top of these other systems? Is Compose trying to be vApp or not? (vApp itself not widely deployed). So a matrix of what ECS can do versus Swarm, etc, would also help. Ultimately, from an outside perspective, it looks like other parties are doing more Docker management a lot better than Docker, and these are moves to catch up, but it's unclear where they fit, and whether they are needed in those contexts. Note: I wrote Ansible, if it's not clear to me, it's a problem -- and this is a common perception around a lot of folks I talk to :) Consider presenting things for different learning styles if you can, especially as the technology doesn't really fit into traditional management patterns - I'm genuinely interested, and probably not the only one having this problem. Again, genuinely interested in wanting to keep up.
- WestCoastJustin 11y ago
  What I think needs to happen, is they need to define some examples problems, then work through how you would solve them with Docker. A high level overview with diagrams, workflow diagrams, tools, commands, supporting docs. When you have AWS, Google, DigitalOcean, etc. all supporting Docker, there needs to be tons of docs, with extremely clear use cases, and implementation guides. Unfortunately, this takes time.. I think they are starting to do something like that with a few screencasts I have been. They almost need a weekly screencast or something ;) There is a super high demand for this type of content, I created a couple screencasts about containers and docker, and still receive a few requests a week for more. It works wonders, when you can actually show people how it works, show them how it will save time, show them how it will improve workflow. Screencast + transcript + code has worked really well for me. Here are some examples: Docker: https://sysadmincasts.com/episodes/31-introduction-to-docker https://sysadmincasts.com/episodes/31-introduction-to-docker Vagrant: https://sysadmincasts.com/episodes/42-crash-course-on-vagrant-revised https://sysadmincasts.com/episodes/42-crash-course-on-vagran... Ansible: https://sysadmincasts.com/episodes/43-19-minutes-with-ansible-part-1-4 https://sysadmincasts.com/episodes/43-19-minutes-with-ansibl...
  - mpdehaan2 11y ago
    That with posted solutions might be good. I'd prefer a non-screencast though, so it would be easier to go at your own pace, and jump back and review things easily. Maybe it's content WITH a screencast, but I'm finding the whole trend of tech-videos to be waaaay too time consuming compared to good reference material (things that are searchable and skimmable). Different people may have different levels of time to get immersed in it though. All being said, I loved the docker "simulator" CLI. This is a good thing. Aside: I don't really love the docker CLI in general, because of the whole SHA editing-existing-VM type of use cases, but there are good parts. In prod, you can skip most of that as you're building from Docker files and it gets a lot simpler, but it almost seems to try to tell you you build images interactively, and Docker files are a better way that skips those parts. It really feels better to me in a workflow where it's used as an image build system. But using the CLI in the way that generates new SHAs and uploads is weird, and (maybe this has changed) being able to accidentally upload your image to the public so easily is sketchy :) That's probably changed since I've looked at it. Another reason for more docs on workflow and showing how to put it all together into a production env. So maybe don't be proscriptive, but show people who are deploying from scratch, and maybe those that have never even used AWS, how to do that, and what the (I shudder to say the word) "best practice" workflow for using Dockerfiles and Dockerhub might be, with all of these components used in concert.

by numo16 11y ago

mpdehaan2 11y ago

Yeah, I read that back in the day, and I'm still finding it hard to follow. I'm trying to pass on some marketing advice here mostly. Leaving it to the reader to try to assemble a video down into their brains, because they have problems with the text wall (particularly visual learners) is probably not a good thing. I work best off examples and pictures. I'd benefit hugely by having a list of the CLI commands, without the text filler, showing a few use cases end to end. I have a hard time keeping all the video in my brain all at once. Just seeing the bash history alone, with some light text commentary, would work for me better than the video -- by a lot. I know different people learn differently. Show all three tools delivering a "pet store" type stack maybe. Tell me when do I want compose and when can I skip it, as quickly as possible. I know these are things you can figure out in several hours/days by trying them all, but for those of us that don't have time, it needs to be presented at a higher level showing how they connect, rather than the marketing speak "it works great together" and then pages that contradict that by saying the integration is minimal. The current result is everyone's Docker topology is VERY different. I know it's not proscriptive, but it's a bit of a mess. I've encountered a lot of people doing lightweight cloud with Docker (basically no-cloud) with Ansible and manual instance management, for instance, and there SHOULD be better options - but I think people go that route because they are confused about the complexity of options they have. Back down to technical bits, I see the line "we're working with AWS to make Swarm usable on ECS", etc, as confusing and a bit marketey (as to the reason for the integration). Why do I need Swarm on ECS? Make the case, etc, these already appear to be container orchestrators. What does Swarm add on top of these other systems? Is Compose trying to be vApp or not? (vApp itself not widely deployed). So a matrix of what ECS can do versus Swarm, etc, would also help. Ultimately, from an outside perspective, it looks like other parties are doing more Docker management a lot better than Docker, and these are moves to catch up, but it's unclear where they fit, and whether they are needed in those contexts. Note: I wrote Ansible, if it's not clear to me, it's a problem -- and this is a common perception around a lot of folks I talk to :) Consider presenting things for different learning styles if you can, especially as the technology doesn't really fit into traditional management patterns - I'm genuinely interested, and probably not the only one having this problem. Again, genuinely interested in wanting to keep up.

WestCoastJustin 11y ago
What I think needs to happen, is they need to define some examples problems, then work through how you would solve them with Docker. A high level overview with diagrams, workflow diagrams, tools, commands, supporting docs. When you have AWS, Google, DigitalOcean, etc. all supporting Docker, there needs to be tons of docs, with extremely clear use cases, and implementation guides. Unfortunately, this takes time.. I think they are starting to do something like that with a few screencasts I have been. They almost need a weekly screencast or something ;) There is a super high demand for this type of content, I created a couple screencasts about containers and docker, and still receive a few requests a week for more. It works wonders, when you can actually show people how it works, show them how it will save time, show them how it will improve workflow. Screencast + transcript + code has worked really well for me. Here are some examples: Docker: https://sysadmincasts.com/episodes/31-introduction-to-docker https://sysadmincasts.com/episodes/31-introduction-to-docker Vagrant: https://sysadmincasts.com/episodes/42-crash-course-on-vagrant-revised https://sysadmincasts.com/episodes/42-crash-course-on-vagran... Ansible: https://sysadmincasts.com/episodes/43-19-minutes-with-ansible-part-1-4 https://sysadmincasts.com/episodes/43-19-minutes-with-ansibl...
- mpdehaan2 11y ago
  That with posted solutions might be good. I'd prefer a non-screencast though, so it would be easier to go at your own pace, and jump back and review things easily. Maybe it's content WITH a screencast, but I'm finding the whole trend of tech-videos to be waaaay too time consuming compared to good reference material (things that are searchable and skimmable). Different people may have different levels of time to get immersed in it though. All being said, I loved the docker "simulator" CLI. This is a good thing. Aside: I don't really love the docker CLI in general, because of the whole SHA editing-existing-VM type of use cases, but there are good parts. In prod, you can skip most of that as you're building from Docker files and it gets a lot simpler, but it almost seems to try to tell you you build images interactively, and Docker files are a better way that skips those parts. It really feels better to me in a workflow where it's used as an image build system. But using the CLI in the way that generates new SHAs and uploads is weird, and (maybe this has changed) being able to accidentally upload your image to the public so easily is sketchy :) That's probably changed since I've looked at it. Another reason for more docs on workflow and showing how to put it all together into a production env. So maybe don't be proscriptive, but show people who are deploying from scratch, and maybe those that have never even used AWS, how to do that, and what the (I shudder to say the word) "best practice" workflow for using Dockerfiles and Dockerhub might be, with all of these components used in concert.