Memory Usage
Closed this issue · 9 comments
Scott, I'm sure you know about this problem, but I would like to raise this issue so that we can solve it. What could be the reason for incorrect transmission of information on memory usage and paging? Have you investigated this problem again? What ideas? This is a very important point in our monitoring project.
This issue has bothered me for almost a year. I reported the problem to Cloud Foundry, the developers of the gosigar library, and they attempted a fix. However, by the time they implemented it, I was done with my initial redo of this project. So I've only recently seen that the issue persists.
In short, the problem is trying to get system info from inside a Docker container. By design containers are isolated from being able to execute code on the host. So, the memory and swap information we get is for the container's OS, not the host's. I've been trying to find a "sysinfo" style utility that could be read from an open port on the host -- similar to the OpenVPN management interface. No joy thus far.
The other option that occurs to me is a cron job running on the host, that would write the needed info to a file in /etc/openvpn. But it would need to be installed manually by the user, and likely wouldn't get done. The bottom line is I'm looking for ideas. :-)
Scott, listen. Or maybe we should take the project away from working in a container altogether? There are too many problems. In fact, the mapping of memory resources and paging is connected only from the container. Also, each time you need to change the Multiarch.dockerfile file itself and rebuild the image.
Maybe it's easier for us to make the binary file work in the service? For example, it would be possible to compile new builds in the archive every time. Download an archive in which there will be just a script that creates, for example, a folder in /opt/openvpn-admin and copies the data structure as a container to the openvpn-gui-tap folder, the scripts folder and the file start.sh . Next, the script creates a service in which the script is executed start.sh and a link to its launch. This way we will solve the problem with displaying memory resources and it will be easier to update the product.
What do you say?
Also, deploying docker and portainer itself on a server where only openvpn is used is too resource-intensive. Only these projects consume a lot of resources. More than OpenVPN itself.
I think it's a good idea to opt out of using OpenVPN Admin in a container. Since I don't see any special advantages of the reverse, that is, using the project in a container.
Shura, I appreciate where you're coming from on this issue, however I am a Docker devotee. It is so nice for development, in terms of being able to deploy and remove packages quickly with no concerns about settings being changed or bits being left behind. My servers run many things, and docker makes them efficient for me to manage and maintain.
Docker makes the build process very easy for multiple architectures as well. I use a "buildx cluster" which is initiated by a single command, and has container-based workers on each of the native architectures (amd64, arm64, armv7). Builds are fast, with no worries about compatibility and testing on all the many variations of Linux.
I'll figure something out on this issue. I need to take a closer look at the gosigar library to figure out where they're deriving their data. I remember thinking earlier in the year that their approach may not be compatible with Debian 11 -- which is the base OS for the container.
Scott, I'm not against the container, I thought it would be possible to do the release of assemblies in the form of archives in parallel, for those who do not want to use the container. Thus, we will expand the scope of use of our project. Since there are small prods in which there is no need to use docker. It's just a wish! We could archive the project and put everything we need using a script as an alternative solution for docker. What do you say?
As for the crontab script, it looks like a crutch, it's not exactly an elegant solution. Although it is possible to implement the task of creating an event through a script when deploying a container. User actions are not needed here.
I've re-opened this issue with Cloud Foundry. In the meantime though, I believe I've figured out how to address it. The method Cloud Foundry is using isn't compatible with Debian 11. However, I've been able to get the data I need using an awk command inside the container, so now I just need to write the equivalent in Go. Implementation shouldn't be too far away -- later this week I would think.
Scott, this is good news. I agree that you should not wait for Cloud Foundry's response so quickly, and even more so for a universal solution that will not be broken in the future. It's a great idea to take the initiative into your own hands and make an owl decision, I fully support it.
I'm not good at programming, but I know html and css, and a bit of js. He is also very good at testing projects. I think we will take the project to a new level together. It will justify the prefix "Plus" :)
I am looking forward to updating the solution to this bug with impatience.
