-
Notifications
You must be signed in to change notification settings - Fork 391
Images, Volumes, Networks, Machines... #19
Comments
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++ |
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 💥 |
Ok, so I had an idea re:
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... |
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 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. |
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. |
Well books... Small problem. Cuberite has no support for books atm. |
@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... |
@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. Now the only disadvantage is the long |
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. |
@aduermael I agree. Lets continue to use one container with some I'm going to start drawing up some prototypes in MagicaVoxel so we can agree on a "UI" before I start writing some code 😝 |
Sorry for being OT. /BR |
Hi @egut - here you go https://github.com/dave-tucker/minecraft-demo |
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. |
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. |
@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. |
@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. |
Thanks for the input. |
I still use it all the time! |
what about a 2d-fallback mode like: https://www.youtube.com/watch?v=TgWibgp2NwM ? |
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:
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!
The text was updated successfully, but these errors were encountered: