lazydocker

image.png

A simple terminal UI for both docker and docker-compose, written in Go with the gocui library.

CircleCI
Go Report Card
GolangCI
GoDoc
GitHub repo size
GitHub Releases
GitHub tag
homebrew

Gif

Demo

Minor rant incoming: Something’s not working? Maybe a service is down. docker-compose ps. Yep, it’s that microservice that’s still buggy. No issue, I’ll just restart it: docker-compose restart. Okay now let’s try again. Oh wait the issue is still there. Hmm. docker-compose ps. Right so the service must have just stopped immediately after starting. I probably would have known that if I was reading the log stream, but there is a lot of clutter in there from other services. I could get the logs for just that one service with docker compose logs --follow myservice but that dies everytime the service dies so I’d need to run that command every time I restart the service. I could alternatively run docker-compose up myservice and in that terminal window if the service is down I could just up it again, but now I’ve got one service hogging a terminal window even after I no longer care about its logs. I guess when I want to reclaim the terminal realestate I can do ctrl+P,Q, but… wait, that’s not working for some reason. Should I use ctrl+C instead? I can’t remember if that closes the foreground process or kills the actual service.

What a headache!

Memorising docker commands is hard. Memorising aliases is slightly less hard. Keeping track of your containers across multiple terminal windows is near impossible. What if you had all the information you needed in one terminal window with every common command living one keypress away (and the ability to add custom commands as well). Lazydocker’s goal is to make that dream a reality.

Requirements

  • Docker >= 1.13 (API >= 1.25)
  • Docker-Compose >= 1.23.2 (optional)

Installation

Homebrew

Normally lazydocker formula can be found in the Homebrew core but we suggest you to tap our formula to get frequently updated one. It works with Linux, too.

Tap:

1
brew install jesseduffield/lazydocker/lazydocker

Core:

1
brew install lazydocker

Binary Release (Linux/OSX)

You can manually download a binary release from the release page.

Automated install/update, don’t forget to always verify what you’re piping into bash:

1
curl https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh | bash

Go

Required Go version >= 1.8

1
go get github.com/jesseduffield/lazydocker

Arch Linux AUR

You can install lazydocker using your AUR package manager of choice or by running:

1
2
3
git clone https://aur.archlinux.org/lazydocker.git ~/lazydocker
cd ~/lazydocker
makepkg --install

A development version of the AUR package is also available

Docker

Docker Pulls
Docker Stars
Docker Automated

  1. Click if you have an ARM device

    • If you have a ARM 32 bit v6 architecture

      1
      2
      3
      4
      5
      docker build -t lazyteam/lazydocker \
      --build-arg BASE_IMAGE_BUILDER=arm32v6/golang \
      --build-arg GOARCH=arm \
      --build-arg GOARM=6 \
      https://github.com/jesseduffield/lazydocker.git
    • If you have a ARM 32 bit v7 architecture

      1
      2
      3
      4
      5
      docker build -t lazyteam/lazydocker \
      --build-arg BASE_IMAGE_BUILDER=arm32v7/golang \
      --build-arg GOARCH=arm \
      --build-arg GOARM=7 \
      https://github.com/jesseduffield/lazydocker.git
    • If you have a ARM 64 bit v8 architecture

      1
      2
      3
      4
      docker build -t lazyteam/lazydocker \
      --build-arg BASE_IMAGE_BUILDER=arm64v8/golang \
      --build-arg GOARCH=arm64 \
      https://github.com/jesseduffield/lazydocker.git

  2. Run the container

    1
    2
    3
    4
    docker run --rm -it -v \
    /var/run/docker.sock:/var/run/docker.sock \
    -v /yourpath:/.config/jesseduffield/lazydocker \
    lazyteam/lazydocker
    • Don’t forget to change /yourpath to an actual path you created to store lazydocker’s config

    • You can also use this docker-compose.yml

    • You might want to create an alias, for example:

      1
      echo "alias lzd='docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock -v /yourpath/config:/.config/jesseduffield/lazydocker lazyteam/lazydocker'" >> ~/.zshrc

For development, you can build the image using:

1
2
3
4
5
6
7
git clone https://github.com/jesseduffield/lazydocker.git
cd lazydocker
docker build -t lazyteam/lazydocker \
--build-arg BUILD_DATE=`date -u +"%Y-%m-%dT%H:%M:%SZ"` \
--build-arg VCS_REF=`git rev-parse --short HEAD` \
--build-arg VERSION=`git describe --abbrev=0 --tag` \
.

If you encounter a compatibility issue with Docker bundled binary, try rebuilding
the image with the build argument --build-arg DOCKER_VERSION="v$(docker -v | cut -d" " -f3 | rev | cut -c 2- | rev)"
so that the bundled docker binary matches your host docker binary version.

Usage

Call lazydocker in your terminal. I personally use this a lot so I’ve made an alias for it like so:

1
echo "alias lzd='lazydocker'" >> ~/.zshrc

(you can substitute .zshrc for whatever rc file you’re using)

  • Basic video tutorial here.
  • List of keybindings
    here.

Cool features

everything is one keypress away (or one click away! Mouse support FTW):

  • viewing the state of your docker or docker-compose container environment at a glance
  • viewing logs for a container/service
  • viewing ascii graphs of your containers’ metrics so that you can not only feel but also look like a developer
  • customising those graphs to measure nearly any metric you want
  • attaching to a container/service
  • restarting/removing/rebuilding containers/services
  • viewing the ancestor layers of a given image
  • pruning containers, images, or volumes that are hogging up disk space

Contributing

There is still a lot of work to go! Please check out the contributing guide.
For contributor discussion about things not better discussed here in the repo, join the slack channel

Slack

If you would like to support the development of lazydocker, please donate

Donate

Social

If you want to see what I (Jesse) am up to in terms of development, follow me on
twitter or watch me program on
twitch

FAQ

How do I edit my config?

By opening lazydocker, clicking on the ‘project’ panel in the top left, and pressing ‘o’ (or ‘e’ if your editor is vim). See Config Docs

How do I get text to wrap in my main panel?

In the future I want to make this the default, but for now there are some CPU issues that arise with wrapping. If you want to enable wrapping, use gui.wrapMainPanel: true

How do you select text?

Because we support mouse events, you will need to hold option while dragging the mouse to indicate you’re trying to select text rather than click on something. Alternatively you can disable mouse events via the gui.ignoreMouseEvents config value

Does this work with Windows?

Currently not unless you use WSL. Instructions for setting up docker for WSL can be found here here

Why can’t I see my container’s logs?

By default we only show logs from the last hour, so that we’re not putting too much strain on the machine. This may be why you can’t see logs when you first start lazydocker. This can be overwritten in the config’s commandTemplates

If you are running lazydocker in Docker container, it is a know bug, that you can’t see logs or CPU usage.

Alternatives

  • docui - Skanehira beat me to the punch on making a docker terminal UI, so definitely check out that repo as well! I think the two repos can live in harmony though: lazydocker is more about managing existing containers/services, and docui is more about creating and configuring them.
  • Portainer - Portainer tries to solve the same problem but it’s accessed via your browser rather than your terminal. It also supports docker swarm.

数据库备份恢复容器化项目实践经验总结

数据库备份恢复容器化项目实践经验总结

本文分享了唯品会数据库Docker的异地容灾项目实践经验,项目中针对用户数据库的异地恢复场景的需求进行开发和测试,整合了网络,存储、调度、监控,镜像等多个模块。在实施完成后,从技术上总结关于选型、开发、踩坑、测试等方面的经验。

项目背景

数据库Docker的异地备份恢复容灾项目,针对用户数据库的异地备份恢复场景的需求进行开发和测试,整合了容器网络、存储、调度、监控、镜像等多个模块。同时针对数据库的日常运维工作开发了监控、资源调度、日志、Puppet自动推送等工具。

通过Docker天生隔离性和快速部署等特点,实现在单台物理机上运行多个数据库备份/恢复实例,大大提高服务器使用率,节省大量成本。通过对Docker本身和相关组件的研究和改造,从普通开源产品落地到公司内部生产环境,积累宝贵的开发经验。通过对Docker已经在其上层运行的数据库日常运维和监控,也积累宝贵的Docker运维经验,为更大规模推广容器提供基础。

image.png

关于容器技术

通过实践,证明容器技术在易用性,可管理性,快速部署具备天然的优势。在资源利用率方面,容器部署在上百个物理节点上,提供约500多个数据库灾备实例,提升了硬件资源的利用率,节约了约400台物理机的采购成本。这些是容器技术带来的实实在在收益。在资源分配与隔离方面,又不输于虚拟机。CPU、内存、磁盘IO、网络IO限流等技术的应用,保证了资源的合理使用,从机制上阻止了单一实例的资源过分消耗的问题。

稳定性是使用容器技术非常关注的一个点,也是基石。MySQL备份/恢复属于CPU密集 + 磁盘IO密集 + 网络IO密集型业务,对于Docker daemon是个较大的考验。就目前来看,限制每台宿主机的容器数量(5个左右)的情况下,集群跑了三个多月没有出现因为容器负载过大导致的crash现象,还是值得信赖的。遇到的唯一相关问题是Docker daemon挂死,具体现象是docker info、docker ps没有响应,docker volume、docker images 正常,下面的容器运行正常。这是偶发事件,无法重现,以后需要继续观察。

由于容器以进程方式存在,体现出几乎与物理机上相当的性能,Overheads极低(低于10%)。从数据抽取任务的结果来看,与物理机相比,使用容器对成功率没有影响,效率也差不多。这也很符合最初预想,不管跑容器还是外部服务从物理机角度来说它们之间是没有什么区别的,都是一个进程,唯一不同是父进程不一样而已。

以上是容器“RUN”带来的好处,通过统一开发流程,应用微服务化,CI/CD等方面的改进,能够进一步利用容器“BUILD”、“SHIP” 优势,容器技术还来的潜力是巨大的。要说容器技术的缺点,还真的不明显。硬要提的话一个是需要一定的学习成本,改变开发流程与方式,一个是开发人员对容器技术的接受程度。这个项目仅用了不到二百人/天,对于一个采用新技术的项目来说,真的是很低的了。一开始我们也担心因为采用新技术导致开发推广有困难,后来实际能通过技术上解决问题,打消了大部分用户对使用Docker的疑虑,反而有助于该技术的普遍应用。

关于Docker daemon版本的选择,我们之前是有过一些讨论的。现在Docker社区非常活跃,当时我们用1.10.3, 到现在已经出了两个新版本了。在功能满足的前提下,稳定性是第一考量。Docker自1.9.0引入CNM网络模型,1.10算是比较成熟。CNM是我们希望在这个项目尝试的一部分。网络与Volume插件功能与稳定性的提升,开始支持磁盘IO读写限速,Device Mapper的支持,等等,都是选择了这个版本的原因。另外,Docker插件的引入,很好地解耦了Docker与底层模块的关系,使我们可以专注于底层(网络、存储)实现而不需要修改Docker daemon本身,同时避免产生升级依赖。

关于容器存储

容器外部卷使用Convoy,以插件的形式支持容器持久化数据。容器本身与外部卷均使用Device Mapper作为底层。没有选择分布式存储原因,主要是为了简化实现,更稳定。通过限制每个容器的BlkioDeviceReadBps、BlkioDeviceWriteBps、BlkioDeviceReadIOps、BlkioDeviceWriteIOps,使磁盘IO稳定地达到相当于95%物理机性能。

image.png

对于Device Mapper,因为是红帽推荐的,而OS又是用的CentOS7.2, 所以就用了它。测试过程中发现Device Mapper健壮性不是很好,仅仅在低并发下,也会出现容器删除失败的情况,容器并发启停偶尔出现找不到设备的情况。这种使用映射关系的设备,功能是丰富,实现上过于复杂,每次对设备的修改都需要额外去更新Metadata,并发场景出错的机会就大了。让我再选的话我会考虑Overlay这种更简单的driver。

对于Convoy,是来自Rancher的产品,Go语言,仍然处于未成熟阶段,版本号0.5, 并没有完全实现Volume Plugin接口。相比其它模块它的问题也是最多的,例如Volume创建失败,无法删除,UNIX Socket泄漏,重名冲突,异常自动退出等。属于能用,但未完善的状态,你自己得有一定开发调试能力去解决发现的问题。其它几个存储插件情况也差不多,Flocker、Blockbridge、Horcrux等等,有的连第一个正式发布版都还没有,Convoy反而相对好点,有点烂柿子堆里挑的感觉。

关于容器监控

容器监控在这个项目里还可以有很大的空间可以改进。项目里用的是cAdvisor,容器内top、free、iostat命令劫持,基于已有的Zabbix体系作数据收集与展示。结论是Zabbix完全不合适做容器监控,数据收集密度,展示质量,灵活度都没能满足需求。

后来在测试中尝试使用Telegraf + InfluxDB + Grafana。 只需要Grafana简单的配置,能够帮忙我们清晰地展示容器及服务进程CPU、内存、网络、磁盘等情况。Grafana上SQL查询语句的调试与开发,确实需要不少的时间,但这个工作量是一次性的。因为是Go写的,Telegraf CPU占用属于比较低的水平(0.4 – 5%)。功能上比较丰富,同时支持外部进程与容器的数据收集,多达55种数据源插件,有它就不需要布cAdvisor了,个人比较推荐。需要告警的同学,可以考虑把influxDB改成Prometheus。它包含Alertmanager实现Email、PagerDuty等消息通知。数据Backend可以选择自带的DB,也可以外接influxDB、Graphite、OpenTSDB等流行方案。

image.png

监控领域业界已经有很多开源方案可以参考,以下是要衡量的标准:易扩展、开销低、入侵小、大集中、易部署、实时性、展现清晰灵活。这方面希望与各位有更多的交流。

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×