Lazydocker: a terminal GUI for Docker(github.com)
github.com
Lazydocker: a terminal GUI for Docker
https://github.com/jesseduffield/lazydocker/blob/master/README.md
48 comments
Yes, +1!
I love ncurses and I appreciate every moment I can do my work / some task with a super-fast TUI app instead of using one of these bloated electron-apps or web ui's.
I want to add: * newsbeuter (rss aggregator) * nmtui (network manager)
BTW I don't think that the constraints you are talking about just have to be constraints - I like to think of them as a measure to standardize software. Also the keybindings play a big role which is another feature of many unix tools I love ('e' for edit and 'q' for quit is just crystal-clear no matter where you come from).
I love ncurses and I appreciate every moment I can do my work / some task with a super-fast TUI app instead of using one of these bloated electron-apps or web ui's.
I want to add: * newsbeuter (rss aggregator) * nmtui (network manager)
BTW I don't think that the constraints you are talking about just have to be constraints - I like to think of them as a measure to standardize software. Also the keybindings play a big role which is another feature of many unix tools I love ('e' for edit and 'q' for quit is just crystal-clear no matter where you come from).
> I also believe that constraints boost creativity and the fixed amount of rows/colums in a terminal and limited set of colors is great for that.
I agree and it's similar for web vs mobile apps. It would be great to come up with design constraints for web apps, but more like Jupyter where you have a way to mix text and graphics. Perhaps a web framework for creating admin tools that can include graphs?
I agree and it's similar for web vs mobile apps. It would be great to come up with design constraints for web apps, but more like Jupyter where you have a way to mix text and graphics. Perhaps a web framework for creating admin tools that can include graphs?
Ngrok is also great!
There is also Dry - https://moncho.github.io/dry/
The best part about dry is using it through docker itself.
The best part about dry is using it through docker itself.
Oh thanks for sharing!
I found this one more "mature"
If you like this you might like Glances. I use it on my home cluster to monitor Docker quickly. You can pull it up in a browser for extra laziness.
https://nicolargo.github.io/glances/
https://nicolargo.github.io/glances/
I wish gocui had a simpler us-ascii based theme so I wouldn't have to fix utf-8 when connecting to remote in screen.
When did terminals get clickables?
ncurses had its support written in September 1995. SysV4 curses had support earlier. I haven't been able to point exactly when xterm gained mouse support to send the data to terminal programs, but definitely before September 1995.
It's been a while, I've been using Vim that way for ~5 years now. It's just less well-known, but it works very well!
tmux tab number can be clicked too.
Yeah, I actually switched from MacVim + Terminal to iTerm + tmux + terminal VIM once I realized mouse support existed.
Bonus is that I can work remotely through SSH with that exact same setup!
Bonus is that I can work remotely through SSH with that exact same setup!
:set mouse=aI don't know but Since QBasic since I used it there.
I started using them for my TUI apps in late 1997, so sometime before that.
You may want to add high up the documentation that it works with both regular docker and docker-compose.
Without watching the whole video... I would have come away with the impression that it only works with compose.
Without watching the whole video... I would have come away with the impression that it only works with compose.
any trick to make it look good on a terminal with a light background? not very readable for me.
I've just released a new version which works better with light backgrounds, so feel free to give that a shot and let me know your thoughts :)
Thanks! Looks much better :-)
One oddity, not sure if I have just not read the docs enough - but if I start it within the directory of a docker-compose project, it comes up completely blank. But running outside that directory shows all my containers / services (including running images inside the docker-compose project).
One oddity, not sure if I have just not read the docs enough - but if I start it within the directory of a docker-compose project, it comes up completely blank. But running outside that directory shows all my containers / services (including running images inside the docker-compose project).
This is fantastic. Thank you! Really well designed and intuitive. It will save me a lot of hassle monitoring containers on servers.
Nice! Now let it use tmux-style navigation commands instead of a friggen mouse and I'd be happy.
Wonder if this will work in the new windows terminal... would be a good test app if it doesn't.
> Memorising docker commands is hard.
I wouldn't agree. Literally: run, build, delete, ps, rm.
I wouldn't agree. Literally: run, build, delete, ps, rm.
docker logs --tail 1000 -F container-name is kind of a pain
That is a beautiful logo/icon. Also nice tool; will have to try it out.
This is awesome. I want more.
was there no such thing as kitematic?
This being terminal based means it can be used easily over ssh.
Kitematic sucks in every way. I despise it, glad there's something else
I have tried on 3 occasions to get kitematic working locally without success.
Looks really nice. For operational-types things, I do wonder if curses UI's are better than web UI's.
They're more practical: ssh into the server. start the tool. [do your stuff]... close the tool. close ssh session.
With a web UI: ssh into the server. find out you want to check your containers statuses. ssh again while binding some local port to a remote port. start the web UI service. open a browser window. enter the URL. [do your stuff]... close the browser window. go back to the terminal. close the web service. close ssh session.
With a web UI: ssh into the server. find out you want to check your containers statuses. ssh again while binding some local port to a remote port. start the web UI service. open a browser window. enter the URL. [do your stuff]... close the browser window. go back to the terminal. close the web service. close ssh session.
The WebUI port forwards can be made a bit more tolerable by using LocalForward in your ~/.ssh/config [1] assuming you're okay with the forwards being set up every time you log in. I agree that it's still clunky though; in-terminal tooling is generally preferable.
[1]: https://linux.die.net/man/5/ssh_config
[1]: https://linux.die.net/man/5/ssh_config
I tried that in a different context... The problem if you're managing many servers is that you'll have to setup a different local port for each server. When I needed it, I had to go check the .ssh/config each time to figure out which port was bound for this server. Did not save any time.
FWIW `DynamicForward` turns on a SOCKS5 proxy, so a dedicated Firefox profile[0] that has its proxy set to the dynamic forward port will be able to browse as if running on the remote machine. I believe remote DNS resolution, works, too. It still could clash ports if you have the same DynamicForward port for multiple ssh configs, but it can drastically reduce the number of port-collisions
0 = you are of course welcome to try running Chrome with `--proxy-server` et al, but I find Firefox a ton easier to use in that situation
0 = you are of course welcome to try running Chrome with `--proxy-server` et al, but I find Firefox a ton easier to use in that situation
Doesn't have to be that way:
I have an alias to a .sh script that launches Portainer (Docker web UI) on the remote host, sets up an SSH tunnel from the remote exposed portainer port to some <local port> and then launches my web browser at localhost:<local port>.
Instant remote Docker GUI. Really snappy too.
Web doesn't have to be slow and messy if you manage it right.
The Portainer UI could use some improvement but that's beside the point
I have an alias to a .sh script that launches Portainer (Docker web UI) on the remote host, sets up an SSH tunnel from the remote exposed portainer port to some <local port> and then launches my web browser at localhost:<local port>.
Instant remote Docker GUI. Really snappy too.
Web doesn't have to be slow and messy if you manage it right.
The Portainer UI could use some improvement but that's beside the point
do you mind sharing it?
I really wish there would be some easy way to make browsers talk http over stdin/out of a process. Port forwarding can be so messy, you need to allocate ports and multi-hop forwarding (eg bastion hosts) can be a problem etc.
Thanks :) As for TUIs vs web UIs, I believe so. The closer the UI is to the command line, the shorter the feedback loop and the more options for customisation. I'm someone who struggles to context switch so if I can do something without having to leave my terminal it helps keep me focused
yes, they are. For operation thing, console > web interface >> gui applications
Thou, there is 1 big advantage of web interfaces and that you can send a link to it to other person (that can make it better than console for some things).
Thou, there is 1 big advantage of web interfaces and that you can send a link to it to other person (that can make it better than console for some things).
I believe there is a lot of room for TUI tools like this. Modern terminals and TUI libraries are advanced enough to support splits, colors, clicks etc.
Why run a 600mb electron app when a small TUI app will do just fine. Even if it’s a 30mb jar file that needs the jvm to run.
I also believe that constraints boost creativity and the fixed amount of rows/colums in a terminal and limited set of colors is great for that.
It’s not because some of these TUIs run full screen that they need to completely drop the unix philosophy. Apps like Mutt, Tig etc frequently delegate to $EDITOR, diff, w3m and others.
Some of my favourite TUI apps:
* Tmux : windows/panes multiplexer
* Tig : git log/status/blame/stage
* Mutt : email
* Fzf : fuzzy finder
* Irssi : IRC