// RecordedStats contains both the container stats we've received from docker, and our own derived stats from those container stats. When configuring a graph, you're basically specifying the path of a value in this struct
typeRecordedStatsstruct{
ClientStatsContainerStats
DerivedStatsDerivedStats
RecordedAttime.Time
}
// DerivedStats contains some useful stats that we've calculated based on the raw container stats that we got back from docker
typeDerivedStatsstruct{
CPUPercentagefloat64
MemoryPercentagefloat64
}
// Details is a struct containing what we get back from `docker inspect` on a container
// RecordedStats contains both the container stats we've received from docker, and our own derived stats from those container stats. When configuring a graph, you're basically specifying the path of a value in this struct
typeRecordedStatsstruct{
ClientStatsContainerStats
DerivedStatsDerivedStats
RecordedAttime.Time
}
// DerivedStats contains some useful stats that we've calculated based on the raw container stats that we got back from docker
typeDerivedStatsstruct{
CPUPercentagefloat64
MemoryPercentagefloat64
}
// ContainerStats autogenerated at https://mholt.github.io/json-to-go/
// UserConfig holds all of the user-configurable options. The fields here are all in PascalCase but in your actual config.yml they'll be in camelCase. You can view the default config with `lazydocker --config` and you can open the config file with 'o' when the status panel is focused, or use 'e' to edit it in your chosen editor. Be careful: if for example you set a `commandTemplates:` yaml key but then give it no child values, it will scrap all of the defaults and the app will probably crash
typeUserConfigstruct{
// Gui is for configuring visual things like colors and whether we show or hide things
GuiGuiConfig`yaml:"gui,omitempty"`
returnfolders[0].Path,nil
}
// Reporting determines whether events are reported such as errors (and maybe application opens but I'm not decided on that yet because it sounds kinda creepy but I also would love to know how many people are using this program)
// CustomCommands determines what shows up in your custom commands menu when you press 'c'. You can use go templates to access three items on the struct: the DockerCompose command (defaulted to 'docker-compose'), the Service if present, and the Container if present. The struct types for those are found in the commands package
// MouseEvents is experimental at this point. It's purpose is to allow you to focus panels by clicking on them, and allow for clicking on links
MouseEventsbool`yaml:"mouseEvents,omitempty"`
// Theme determines what colors and color attributes your panel borders have. I always set inactiveBorderColor to black because in my terminal it's more of a grey, but that doesn't work in your average terminal. I highly recommended finding a combination that works for you
ThemeThemeConfig`yaml:"theme,omitempty"`
// ShowAllContainers determines whether the Containers panel contains all the containers returned by `docker ps -a`, or just those containers that aren't directly linked to a service. It is probably desirable to enable this if you have multiple containers per service, but otherwise it can cause a lot of clutter
// RestartService is for restarting a service. docker-compose restart {{ .Service.Name }} works but I prefer docker-compose up --force-recreate {{ .Service.Name }}
// DockerCompose is for your docker-compose command. You may want to combine a few different docker-compose.yml files together, in which case you can set this to "docker-compose -f foo/docker-compose.yml -f bah/docker-compose.yml". The reason that the other docker-compose command templates all start with {{ .DockerCompose }} is so that they can make use of whatever you've set in this value rather than you having to copy and paste it to all the other commands
// StopService is the command for stopping a service
StopServicestring`yaml:"stopService,omitempty"`
// ServiceLogs get the logs for a service. This is actually not currently used; we just get the logs of the corresponding container. But we should probably support explicitly returning the logs of the service when you've selected the service, given that a service may have multiple containers.
ServiceLogsstring`yaml:"serviceLogs,omitempty"`
// ViewServiceLogs is for when you want to view the logs of a service as a subprocess. This defaults to having no filter, unlike the in-app logs commands which will usually filter down to the last hour for the sake of performance.
// RebuildService is the command for rebuilding a service. Defaults to something along the lines of `{{ .DockerCompose }} up --build {{ .Service.Name }}`
// RecreateService is for force-recreating a service. I prefer this to restarting a service because it will also restart any dependent services and ensure they're running before trying to run the service at hand
// ViewContainerLogs is for viewing the container logs in a subprocess. We have this as a separate command in case you want to show all the logs rather than just tail them for the sake of reducing CPU load when in the lazydocker GUI
// ContainerLogs shows the logs of a container. By default this restricts the output to (as of right now) the last hour. This is for the sake of performance, and you can feel free to change this
// AllLogs is for showing what you get from doing `docker-compose logs`. It combines all the logs together
AllLogsstring`yaml:"allLogs,omitempty"`
// ViewAllLogs is to AllLogs what ViewContainerLogs is to ContainerLogs. It's just the command we use when you want to see all logs in a subprocess with no filtering
ViewAllLogsstring`yaml:"viewAlLogs,omitempty"`
// DockerComposeConfig is the command for viewing the config of your docker compose. It basically prints out the yaml from your docker-compose.yml file(s)
// CheckDockerComposeConfig is what we use to check whether we are in a docker-compose context. If the command returns an error then we clearly aren't in a docker-compose config and we then just hide the services panel and only show containers
// UpdateConfig is currently not being used, but may be used down the line to allow for automatic updates
typeUpdateConfigstruct{
Methodstring`yaml:"method,omitempty"`
}
// GraphConfig specifies how to make a graph of recorded container stats
typeGraphConfigstruct{
Minfloat64`yaml:"min,omitempty"`
Maxfloat64`yaml:"max,omitempty"`
Heightint`yaml:"height,omitempty"`
Captionstring`yaml:"caption,omitempty"`
StatPathstring`yaml:"statPath,omitempty"`
Colorstring`yaml:"color,omitempty"`
// Min sets the minimum value that you want to display. If you want to set this, you should also set MinType to "static". The reason for this is that if Min == 0, it's not clear if it has not been set (given that the zero-value of an int is 0) or if it's intentionally been set to 0.
Minfloat64`yaml:"min,omitempty"`
// Max sets the maximum value that you want to display. If you want to set this, you should also set MaxType to "static". The reason for this is that if Max == 0, it's not clear if it has not been set (given that the zero-value of an int is 0) or if it's intentionally been set to 0.
Maxfloat64`yaml:"max,omitempty"`
// Height sets the height of the graph in ascii characters
Heightint`yaml:"height,omitempty"`
// Caption sets the caption of the graph. If you want to show CPU Percentage you could set this to "CPU (%)"
Captionstring`yaml:"caption,omitempty"`
// This is the path to the stat that you want to display. It is based on the RecordedStats struct in container_stats.go, so feel free to look there to see all the options available. Alternatively if you go into lazydocker and go to the stats tab, you'll see that same struct in JSON format, so you can just PascalCase the path and you'll have a valid path. E.g. ClientStats.blkio_stats -> "ClientStats.BlkioStats"
StatPathstring`yaml:"statPath,omitempty"`
// This determines the color of the graph. This can be any color attribute, e.g. 'blue', 'green'
Colorstring`yaml:"color,omitempty"`
// MinType and MaxType are each one of "", "static". blank means the min/max of the data set will be used. "static" means the min/max specified will be used
MinTypestring`yaml:"minType,omitempty"`
// MaxType is just like MinType but for the max value
MaxTypestring`yaml:"maxType,omitempty"`
}
// StatsConfig contains the stuff relating to stats and graphs
typeStatsConfigstruct{
Graphs[]GraphConfig
// Graphs contains the configuration for the stats graphs we want to show in the app
Graphs[]GraphConfig
// MaxDuration tells us how long to collect stats for. Currently this defaults to "5m" i.e. 5 minutes.
// CustomCommand is a template for a command we want to run against a service or container
typeCustomCommandstruct{
Attachbool
// Attach tells us whether to switch to a subprocess to interact with the called program, or just read its output. If Attach is set to false, the command will run in the background. I'm open to the idea of having a third option where the output plays in the main panel.
Attachbool
// Command is the command we want to run. We can use the go templates here as well. One example might be `{{ .DockerCompose }} exec {{ .Service.Name }} /bin/sh`
Commandstring
}
// GetDefaultConfig returns the application default configuration
// NOTE: do not default a boolean to true, because false is the boolean zero value and this will be ignored when parsing the user's config
// NOTE (to contributors, not users): do not default a boolean to true, because false is the boolean zero value and this will be ignored when parsing the user's config
Jesse Duffield
5 years ago