Closed ghost closed 3 years ago
Merging #31 (0ade632) into main (c12079e) will decrease coverage by
0.14%
. The diff coverage isn/a
.
@@ Coverage Diff @@
## main #31 +/- ##
==========================================
- Coverage 37.04% 36.89% -0.15%
==========================================
Files 10 10
Lines 1347 1347
==========================================
- Hits 499 497 -2
- Misses 779 780 +1
- Partials 69 70 +1
Impacted Files | Coverage Δ | |
---|---|---|
bot/util.go | 54.28% <0.00%> (-2.86%) |
:arrow_down: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update c12079e...0ade632. Read the comment docs.
Slightly modified some existing REPLs to use official images from Docker Hub. Feel free to leave out this change, Docker Hub pull limits aren't great.
So the reason why I modified the official image is because I feel like 50+% of the time in the ubuntu image you spend on apt update
(mostly) and apt install
for the basics, which is why I think I'd like to keep my modified images. Could you remove those changes from your PR and then I'll merge it.
You could make "ubuntu-official" maybe if you really want, though that may be confusing and unweildy.
We could also make a docker
image and make a way to pass arguments to a script, so I could just say @replbot docker:ubuntu
for instance. That'd be kinda cool.
Also, I was looking into ways to automatically build and update them automatically via github actions, but that seems to be rather hard: https://github.com/binwiederhier/docker/
Ahh ok, that makes sense! I was trying to think of why it may have been done but didn't even think about that. That's a great point and there really isn't much you can do on the base image without updating the package repo + adding some basic packages.
I'll go ahead and revert those changes - certainly don't want to make things unnecessarily complex. Adding a feature such as being able to pull any Docker image would be awesome, I'll start tinkering around with that.
I've also been playing with setting --memory
and --cpu
flags on the containers to limit their available resources, hoping to maybe work that into the global config so there isn't a need to do it individually per each REPL script. (Makes it a bit harder to cripple the host the containers are running on when something goes wonky) I'll look into a mostly hands-off way of updating Docker images and publishing them, but a workflow integrated with Github would be definitely be awesome 🤔
I've also been playing with setting --memory and --cpu flags on the containers to limit their available resources, hoping to maybe work that into the global config so there isn't a need to do it individually per each REPL script. (Makes it a bit harder to cripple the host the containers are running on when something goes wonky) I'll look into a mostly hands-off way of updating Docker images and publishing them, but a workflow integrated with Github would be definitely be awesome thinking
This is so funny. I literally just had a co-worker ask about fork bombs and I tried it and it more or less crashed the host. So I'll try to put some limits in place. I've had a ticket for this for a while (https://github.com/binwiederhier/replbot/issues/10).
As for the common stuff, you could make a helpers/docker-run
script.
Apparently containers can also talk to each other, which I think is less of an issue than the memory and ulimit stuff.
This is where I am right now: docker run --cpus=.5 --ulimit="nofile=200" --kernel-memory=10M --memory=100M -it binwiederhier/ubuntu
I was also looking at --cap-drop all
and then re-adding caps manually, see https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html -- But I have to stop now for actual work
I'm gonna merge and modify. Thanks for your contribution. Keep them coming.
@axitedotdev See here: https://github.com/binwiederhier/replbot/commit/8b8220738d20b5ecaec4108b077e68348f7df699
This should make it safe against fork bombs and give it some sane defaults for ram and cpu. I'm gonna look into disk now.
I've also been playing with setting --memory and --cpu flags on the containers to limit their available resources, hoping to maybe work that into the global config so there isn't a need to do it individually per each REPL script. (Makes it a bit harder to cripple the host the containers are running on when something goes wonky) I'll look into a mostly hands-off way of updating Docker images and publishing them, but a workflow integrated with Github would be definitely be awesome thinking
This is so funny. I literally just had a co-worker ask about fork bombs and I tried it and it more or less crashed the host. So I'll try to put some limits in place. I've had a ticket for this for a while (#10).
LOL, my buddies fork bombed mine less than 5 minutes after setting it up. Good fun though. Thanks for the merge, and awesome to see the two changes for container resource limits & disk limits!! Good stuff. Hoping to spend some more time on this after the holiday weekend -- enjoy!
-Slightly modified some existing REPLs to use official images from Docker Hub. Feel free to leave out this change, Docker Hub pull limits aren't great.
-Added the following REPLs that we have been using in our server verified that they work without issue (and provide a ton of fun): Alpine, Amazon Linux, Arch Linux, CentOS, Debian & Fedora.
-Updated readme.md to reflect the added default REPLs.
These added REPLs are all things we found fun to play around with in our server so figured I'd share, and hopefully save someone a few seconds from having to create their own :smile: With that said, it is super easy to add your own.