|
the real value of containers is configuring ports and ip addresses of services in a consistent way instead of configuring 100 services with a 100 different config formats to coexist on one machine you just throw up hand and say gently caress it, everything runs on the default port and we'll just work around it using network namespaces and iptables
|
#
?
Apr 9, 2024 04:33
|
|
|
|
| # ? May 2, 2024 16:58 |
|
|
Perplx posted:the real value of containers is configuring ports and ip addresses of services in a consistent way this is very much it for me. i can put your /config store in a cute little pocket and give you your own very special port and i never have to think about you again
|
|
#
?
Apr 9, 2024 04:35
|
|
|
well-read undead posted:i used ecs for a very short period and let me tell you friend i found it to be excruciatingly bad What didn't you like about it? I haven't bothered with any of the "advanced" features I just set up a basic service in cloud formation and thought that was fine (well, "fine" compared to the background frustration of doing anything in AWS, which is high)
|
|
#
?
Apr 9, 2024 06:29
|
|
|
ADINSX posted:What didn't you like about it? I haven't bothered with any of the "advanced" features I just set up a basic service in cloud formation and thought that was fine (well, "fine" compared to the background frustration of doing anything in AWS, which is high) well, first of all, if i'm ever forced to use cloud formation i will face god and walk backwards into hell but beyond that, i just chafed at the abstractions they chose. it's been a couple years now so i'm fuzzy on details but i remember a lot of friction with the way tasks were defined that made something as simple as rolling out a new version take more steps than should be necessary. and of course the console ui is dogshit but that's literally all of aws, so i just found it very unpleasant to use is all. probably dialed in with some decent management tools that are not anything aws has made it wouldn't be that bad because at the end of day it's just a RUN CONTAINER ON COMPUTER tool
|
|
#
?
Apr 9, 2024 08:40
|
|
|
containers are good, especially for deploying python. namaste
|
|
#
?
Apr 9, 2024 09:44
|
|
|
I disappointed our security team because their agent thing couldn’t run in our containers because they’re chiseled Ubuntu and the /bin and /lib folders are basically empty. Filesystem is so locked down it runs the app copied into it and that’s it.
|
|
#
?
Apr 9, 2024 13:59
|
|
|
you’re security team is a pos
|
|
#
?
Apr 9, 2024 14:23
|
|
|
we use crowdstrike and it understands how containers work its nice
|
|
#
?
Apr 9, 2024 17:40
|
|
|
if one has to run an agent, why wouldn't one run it on the host os? you know, where the containers run?
|
|
#
?
Apr 9, 2024 18:14
|
|
|
git apologist posted:containers are good, especially for deploying python. namaste yes, they are good bandaids for pythons awful versioning issues
|
|
#
?
Apr 9, 2024 18:59
|
|
|
rotor posted:yes, they are good bandaids for pythons awful versioning issues its true, it rules i want more than anything else for this to be solved in a "ok here's how you actually should package and ship applications and this is what our tools provide" but there's already 12 of those and it'll just become #13 but official
|
|
#
?
Apr 9, 2024 19:19
|
|
|
|
| # ? May 2, 2024 16:58 |
|
|
systemtap is another thing that's completely rear end to try and get to run in kubernetes, between permissions and the host/container not having the same versions of poo poo. eBPF is supposed to work as a better replacement for it in kubernetes but still needed a while to cook as far as not requiring specialized expert-level understanding of eBPF to use it outside some pre-configured setup. there's not as much readily available supporting tooling for it yet
|
|
#
?
Apr 9, 2024 19:20
|
|
