3 ms·
if you need to ssh in to a box you are not ready for fargate or lambda. think about what commands you would actually run on the shell. what are you looking for
by foolfoolz 7y ago
if you need to ssh in to a box you are not ready for fargate or lambda. think about what commands you would actually run on the shell. what are you looking for or reading? you can find all that information from cloudwatch or other logs / metric services. you'll find at scale, sshing into a particular ec2 box also doesnt make sense
- fulafel 7y agoSooner or later you end up needing to debug in production to narrow down phenomena that for some reason don't replicate. Repl du jour, aws cli, lsof, tcpdump, netcat, perf, netstat, iptables, poking around in /proc, valgrind, pdb, replacing binaries with shell scripts that log their args, rerunning various subsystems from the shell with debug/verbose switches, retrieving badly configured core dumps etc. If you've been spared from these kinds of issues, be thankful for your so far sheltered life :) If your problem is reproducible at will in prod (big if), theoretically you can bake each thing you try into your container build and debug its automation at each step, often slowing the debugging process down prohibitively.