Add Container metric functionality

[Gituser143]

Description

Add functionality to get overview of containers running by docker and related metrics. Can be accessed using grofer container.

Fixes #91

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Checklist:

• I have read the contribution guidelines and followed it as far as possible.
• I have performed a self-review of my own code (if applicable)
• I have commented my code, particularly in hard-to-understand areas (if applicable)
• I have run go fmt on my code (reference)
• I have made corresponding changes to the documentation (if applicable)
• My changes generate no new warnings
• Any dependent and pending changes have been merged and published

[Gituser143]

@MadhavJivrajani I think I'm done here, pls review and let me know if I've missed/should change anything!

[MadhavJivrajani]

I get this panic with grofer container -c <cid of nginx>
And the panic is not clean, command continue to go on in the background and is a little messy to kill and recover

[Gituser143]

@MadhavJivrajani this is strange, I'm not able to reproduce this issue. Can you tell me what you ran?

[Gituser143]

@MadhavJivrajani Port mappings aren't derived from the ContainerInspect(), I get them directly from ContainerList() itself. The data returned, has ports within it as a field. The type can be found here

[MadhavJivrajani]

Or instead of just IPv4, we could have another column in that table called HostIP, that would make things much clearer.

[Gituser143]

Or instead of just IPv4, we could have another column in that table called HostIP, that would make things much clearer.

This sounds like a good idea, clears more things up!

[MadhavJivrajani]

@MadhavJivrajani Port mappings aren't derived from the ContainerInspect(), I get them directly from ContainerList() itself. The data returned, has ports within it as a field. The type can be found here

Regardless, I would assume that the inspect command too gets its info from the API, just like ContainerList or ContainerStats

[Gituser143]

Regardless, I would assume that the inspect command too gets its info from the API, just like ContainerList or ContainerStats

They are different endpoints, thus have different format entirely.

[MadhavJivrajani]

They are different endpoints, thus have different format entirely.

Right, but whenever you would want to list a particular resource (like ports in this case), it would give a unifrom result, albeit in different formats, is what I meant.

[MadhavJivrajani]

lgtm other than the above comments.

[Gituser143]

@MadhavJivrajani, Okay so for the CPU metrics calculation, making it a function might not be the best idea because, it requires quite a lot of parameters and simply sending each of those individual metrics doesn't seem worth it. The parameters we'd have to send are:

• numCPUs
• CPUStats.CPUUsage
• PreCPUStats.CPUUsage
• CPUStats.SystemUsage
• PreCPUStats.SystemUsage

Each of which are a type defined externally (docker types). So I feel it would be better to leave this as is. What do you think?

[MadhavJivrajani]

From what I can tell, all of them are available in the StatsJSON type. Sending a pointer to that struct to avoid copying sounds good enought to me

[Gituser143]

From what I can tell, all of them are available in the StatsJSON type. Sending a pointer to that struct to avoid copying sounds good enought to me

But if we're doing this, writing tests might get a little messy as we'd have to either fetch a similar stat or populate a struct ourself. Which when I come to think of it, shouldn't be much of an issue. I'll get to it :P

[Gituser143]

@MadhavJivrajani changes have been made! Do let me know if I've missed/messed something up.

[MadhavJivrajani]