Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Images, Volumes, Networks, Machines... #19

Open
aduermael opened this issue Nov 19, 2015 · 19 comments
Open

Images, Volumes, Networks, Machines... #19

aduermael opened this issue Nov 19, 2015 · 19 comments

Comments

@aduermael
Copy link
Contributor

I would like to open a discussion, to see how we could display more informations in Dockercraft, also allow for more ingame interactions with the Docker engine (new levers, buttons...etc).

This is a picture of our original plan:
screen shot 2015-11-19 at 5 54 56 am

The columns with colored stripes were supposed to represent docker images available on the host, with one color per layer. On each image we could have "run" and "remove" buttons (but how would we give parameters when pushing "run"?)

By the way, I'm using Magicavoxel to prototype, it's free and pretty fun.

We should also find a way to represent networks and volumes.

It would be great to consider Docker Machine as well...

Now the big question is, how do we keep Dockercraft simple with all these features? Also, how do we support scale?

It may be unusable with several machines, networks, and hundreds of containers...
Maybe we could have dynamic zones, portals...

I guess we should try to agree on something before rushing on implementation. Let's prototype!

@victort
Copy link

victort commented Nov 19, 2015

Redstone: I would like to propose redstone be used to illustrate links between containers, since redstone has visual states, it should be reasonable to assume links are active or inactive between containers.

Registry representation: If (tags on) images refer to reachable (internal) registries, and the registries are pollable, then can a structure represent a registry, and inside it be the stacks of images, like a library?

Container security: can we add lockable doors? i need to test this.

thanks for your consideration,

US$0.02++

@fungiboletus
Copy link

Can we consider having a grid of containers instead of a line (maybe as an option) ? We would like to have a visual representation of more than 100 containers. The line is good for few containers but it goes too far away very quickly.

Also, is it possible to stop/remove a container when it is destroyed? It can be fun to test resilience / fault tolerance by spawning creepers that randomly destroy containers 💥

@dave-tucker
Copy link
Contributor

Ok, so I had an idea re: docker-machine:

  1. Grab a list of machines from docker-machine ls or ~/.docker/machines
  2. Start one cuberite container per machine (using TCP instead of mounting docker.sock)
  3. Start one final server, which contains a lobby world. This world has portals to each machine world.
  4. Start a bungeecord container. This handles proxying the players connection to each container without disconnect. This exposes port 25565

screenshot 2015-11-20 11 38 45

So when a user logs in to DockerCraft, they see a lobby + portals to each of their docker-machines! A bit like the lobby I used in my DockerCon EU demo...

screenshot 2015-11-15 04 05 53

@victort
Copy link

victort commented Nov 20, 2015

i take it back about redstone to show the links between containers.

Linked containers would make more sense to be in a fenced "yard". (also gates in those fences should be lockable (see spigot/bukkit's lockette mod for the idea))

Ideally this would make it more useful for people using docker-compose, this would allow things like /docker-compose up, which would spawn an entire village of containers in a fenced yard.

Flying over your docker containers would be a great way to visualize the overall health of a cluster! ^_^

Working with others in multiplayer would be a great way to share the management load and "get more eyeballs on" problems!

Especially useful if the idea of a "grid" layout takes hold. The total world/grid size could even concieveably be pre-calculated by the amount of RAM/CPU available for spawning containers.

@victort
Copy link

victort commented Nov 20, 2015

OH, OH, and can we have books deposited in enderchests whenever events are written to a log??

i like the idea of Minecraft-as-a-management-interface WAY too much, my apologies. I'm gonna stfu and go learn LUA now.

@Seadragon91
Copy link

Well books... Small problem. Cuberite has no support for books atm.

@aduermael
Copy link
Contributor Author

@victort I have one concern about links. It's pretty hard to represent complex linking in space. We will have to move containers, that's a lot of cubes and it's kind of expensive...
Also linking containers with Docker networking allows for even more complex liking (across machines for instance). In this case maybe just displaying colored cubes on top of some containers would indicate that they belong to the same network (one single container can be connected to several networks).

@aduermael
Copy link
Contributor Author

@dave-tucker I like what you're describing for machines. But I would make it less complex by running only one Dockercraft server and use libmachine in the go application to get all the informations needed. Each portal would connect you to a different remote API to list containers and end commands... libmachine does all the hard work about using the right certificates...etc

The only thing that I don't like in that implementation, is that the server isn't containerized anymore.
BUT, we could also mount the folders required by libmachine when running the container.
So you could have one local machine to host Dockercraft (and other containers) that would allow you to see ALL other machines as well.

Now the only disadvantage is the long docker run command to run all this... But it's easy with docker compose!

@dstinebaugh
Copy link

Also being a flatland, using a beacon with color matching stained glass (orange or light blue) could be handy for the grid formation as well, letting you see a container change state, even if parallax prevents you from seeing the actual house.

@dave-tucker
Copy link
Contributor

@aduermael I agree. Lets continue to use one container with some libmachine magic 😀

I'm going to start drawing up some prototypes in MagicaVoxel so we can agree on a "UI" before I start writing some code 😝

@egut
Copy link

egut commented Dec 1, 2015

Sorry for being OT.
@dave-tucker I loved your minecraft-demo at DockerCon EU, can I somehow get the code/config used in the demo so I can setup a similar environment my self. Maybe not cross cloud-regions as you did but, cross local machines.
Maybe even have portal or similar to connect to dockercraft to starting/stopping world :)

/BR

@dave-tucker
Copy link
Contributor

Hi @egut - here you go https://github.com/dave-tucker/minecraft-demo

@trafflux
Copy link

I think Minecraft is a nice tool for the 30k ft view (or specifically for teaching) but this has the potential to be way more complicated than necessary. For example, the entire Redstone branch of Minecraft is ridiculously hard to follow, it can/can't move around/under different blocks, its all the same color, and it has to be placed on a flat surface. Imagine trying to trace connections between 20 images. It would look like the end-game of Snake on the old Nokias.

I think MC engine is an interesting UI BUT it needs to fork specifically for docker if its going to be feasible. There's no reason to keep it current with the actual game. We just need an engine and an agreed upon codex. Connections between images, startup params, etc etc etc need to be well thought out for logic, intuitiveness, scale/readability. Do we really need an avatar with pick axes jumping around? In the end we just need a UI that illustrates how everything is connected, what its made of, as well as have a easy to manage interface without needing to memorize command line options. Amazon released a UI tool for AWS recently, while not sexy what-so-ever, satisfies us visually stimulated people a bit. Just my 2 cents.

@bean5
Copy link

bean5 commented Mar 24, 2016

This needs to move. This project has way too much potential. For large organizations, it could really help to know where people are focusing their time when debugging something. In a minecraft world, you'd see the other characters and be able to interact + coordinate. More intuitive in some ways than just chat in some scenarios.

@brandonsturgeon
Copy link

@bean5 This is a fun project, but it doesn't have a place in a professional development. Maybe a startup or something, but this project really shines in teaching people how docker works in a more visual, easy-to-approach way.

@trafflux
Copy link

@brandonsturgeon wow I forgot about this project. I agree its pretty much useful for teaching and that's about it. Although I can imagine some intro to programming for little kids that uses the engine; sort of like how the redstone circuits work but more codey and less semiconductor design. When I first saw all the components in Minecraft I was blown away at the potential, and when I saw what kind of crazy complex systems people made, I was blown away again, but when I actually tried to use the tools in the game for making these redstone/rube-goldberg machines, I was quite frustrated since it takes forever to assemble stuff and the engine has its own limitations.

@bean5
Copy link

bean5 commented Oct 14, 2016

Thanks for the input.

@dstinebaugh
Copy link

I still use it all the time!

@flybyray
Copy link

what about a 2d-fallback mode like: https://www.youtube.com/watch?v=TgWibgp2NwM ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests