Build improvements
till opened this issue · 6 comments
From #182 or #184 — Part of me also thinks you "should" have a scalyr/agent-2-base Docker image which gets pulled into the various flavours. Or maybe some pre-processor to avoid maintaining 4/5 almost identical Dockerfiles.
And maybe some make to avoid typing in lots of commands. But I think that's for a later PR. When the PRs are integrated and working, I can PR a few suggestions if there's any interested. :)
Good idea(s) @till.
For context, we currently script these workflows as part of our internal release process and it seems using those prebuilt images directly has been adequate for most of our customers' use cases.
Question: Besides shrinking the image (alpine), what other use cases do you encounter where you find yourself needing to build Scalyr images?
@echee2 Customization is a big deal — I wish it would offer something which just "expects" an API key to get started. Without having to write my own agent.json with import_vars. Mounting 2-3 things could be avoid and it would work out of the box. All of that would make your image more Docker-like to get started.
The scripting I found a bit hard to grok at first, I would prefer a Makefile instead. The "building a script to run, in order to build a Docker image"-part seems very intransparent. Also, the part where you need to have Python installed — we're using Docker already, why not use an image to build. :-) (But that's IMHO.)
For our "special" use-case, I also had to do more config:
We use your own as a syslog proxy to ship our logs to Scalry.
Context:
- we use Cloud Foundry
- we deploy the agent in a Docker container
- but we can't use any of the Docker container monitoring (e.g. mounting the socket is not possible)
TL;DR — I am using it as a syslog proxy to your service, and then cf drain to send logs there. Not sure if this is too special, but that's the other thing I had to customise for.
Hi @till, thank you for this context and helping us understand your needs better.
Meanwhile I'm wondering if this helps you: if you're not already aware, we have expanded "direct" environment variable support in the most recent release (2.0.46) without having to use import_vars.
We're a little behind in the documentation department here so the public docs haven't been updated -- but basically most global level config params as well as some kubernetes module-level ones now can be directly defined via corresponding SCALYR_XXX environment variable (just like SCALYR_API_KEY).
Note however that if a config param is defined in agent.json or agent.d fragment, it will override any environment variables.
We will be updating the public docs soon.
In the interim you can search for env_aware ( in configuration.py or kubernetes_monitor.py ) for the complete list of environment-aware variables. The environment variable name is simply prepend SCALYR_ to the config param name. For example agent_log_path -> SCALYR_AGENT_LOG_PATH
The exception is if defines a custom env_name, in which case you would use the custom name (for example kubernetes monitor ignore_master -> SCALYR_K8S_IGNORE_MASTER
We can expand support of this to other modules as needed.
@echee2 This is great indeed, I'll take a look whenever the docs are ready. Then we can trim our build considerably.