Yeah I meant exec. In general some commands just feel a bit slower. There is a lag for it to gain context, even if the container is running already. At my last job it was faster to just jump into bash inside the container and pretend it was my computer to run tests and other scripts, etc. But that seems like youre not using docker correctly at that point.

Even just doing docker run <test-command> takes longer than a local run of <test-command>

I am getting a new comp tomorrow and my goal is to not actually install any tools or databases, but I am pretty sure I will give up within a week.

Oh and that is the other annoyance, lots of ide/text editors need some kind of language server and other plugin support to even lint or format correctly, so unless you are vimming inside the docker container, you end up needing to install some stuff

Seems like the wrong question. The answer is the same as the answer to "how would you stop this from happening when Cerebrus is the programmer implementing this on your team", which is, like...code reviews? (I didn't say it was a _great_ answer)

OK but again docker run is starting up the container from scratch.

I decided to do some timings. It looks like a "noop" takes about 200ms to run from outside with docker-exec (compared to less than 1ms inside). That really doesn't seem like enough lag to care.

I have basically nothing installed on this machine except like you know, GUI tools. I work on this laptop, another laptop, and a linux machine upstairs and I can move from one to the other without skipping a beat, it's great.

Most good IDEs have docker support. I find it to be... a little awkward. I am mostly writing python so I have 2 choices:
* have it use the environment from inside my docker container - except I don't always have or want them running
* have a few python virtualenvs that the IDE uses to library resolution
I do the latter. But my IDE takes care of it.

And actually for some of the work I do what I love the most is, bring the container down, bring it back up, it's back to it's default state. I was testing getting an RPM package to work and I had a container set up with everything it needed and the entrypoint was just just "install the package" and I could do it again and again and again super fast, no steps required, just docker run over and over. I used to use vmware and I was always fiddling with restoring save states. Of course in the bad old days we were actually using physical computers.

I remember a place I used to work had a room full of computers with different OSes and versions and if you had a cross platform bug you'd be moving from place to place, uninstalling, reinstalling and trying it out. Hoping you didn't screw up and need to start over. Never really sure if what you were doing would work on a clean machine. Virtual machines were a huuuuge upgrade even though they ran at a small fraction of real speed.

Does image size affect this? My experience at work has been much much worse.

Another thing I would be curious about is how long build commands take vs just running them on your os. A classic example is installing node modules in a docker container ?feels? like it takes much longer.


Pythons virtual env is amazing for dealing with this kind of thing. Unfortunately I work in ruby currently which loves to take 6 hours to install anything and clogs up your system with c libraries.

Also computer is delayed till at minimum Monday so no fun for me

You docker nerds are really warming me up to adding another layer of complication/source of confusion into my dev environment.

I don't know? My images are 1-2Gish

It might. I really doubt it's substantially worse though

It's pretty unusual IME to need a dev environment that is *only* python libraries. You need other utilities, libraries, programs, etc. You probably have custom system config settings and application config settings. Docker means that my prod environment and my dev environment are literally identical. I can even produce whole systems that are *nearly* identical (usually there are going to be some pieces at the edge that are different, such as, our database is RDS but in dev it'll be a mysql container)

As someone who works with AWS a lot, there are these "localstack" containers that make that stuff a lot easier. Basically I can spin up a container that contains fake versions of a lot of AWS stuff (s3, sqs, whatever) so that my dev and test environment is not dependent on access to those.

I?m kind of enjoying the break from aws all the things land. Although it was fun to learn a ton of new applicable stuff. Now I?m just a lowly Ruby on Rails developer

Wait till they want to use kubernetes so you can run your whole backend locally!

So my company finally got a reasonable development work flow in place after years of resistance/blockages and we were actually making good forward progress on the application just in time for them to cancel/sunset the product. Figures.

You guys know any good books or things to read to understand how stuff like sand boxing, docker, containers or virtualization work at the basic OS level? I hardly know the difference and I’m on a team working with a product like that and I always feel so behind.

Udemy got me up to speed on AWS.

I use udemy courses for any tech I want to learn. That combined with tutorials gets me up to speed very quickly.

For a deep dive into containers or virtualization, I?m not sure how much of that they have. YouTube is probably your best bet.

Yea should have clarified, I meant more from how they implement and not so much as an end user. If I wanted to create ASS lambda, how would I go about doing it.

What is ASS lambda? I'm afraid to google that at work.

Lol I meant AWS lambda.

If you're looking for AWS specific stuff, there's usually good content in the videos from AWS ReInvent.

Udemy was great for AWS.

I would start here for a concise intro: https://jvns.ca/blog/2016/10/10/what...s-a-container/

Then dive deeper here: https://www.ianlewis.org/en/containe...on-container-r

For AWS: https://gumroad.com/l/aws-good-parts

I need to learn by doing. Ive found a lot of success with Pluralsight althought its kinda pricey.

Docket is not a Hypervisor

This link might shed some light.

Can someone help me figure out a) why my boss has such a hard-on for event-driven API architecture and b) how to make her happy w/o adding a completely unnecessary asynchronous event layer into our simple REST API?

We're already doing scheduled reports that scrape our logs in cloudwatch - which is pretty much event driven/data lake/whatever you want to call it. But I doubt that's going to satisfy her.

Here's AWS Serverless Event Bus:

I can see plenty of uses for this. But a simple CRUD-ish REST API driven by user interaction where the user is expecting an immediate response is not one of them.

My boss asks me like once a month how we're coming on a "data lake" despite me telling him that's not what we do. Buzzword compliance is a thing.

Yeah my boss is big into that too. She's not gonna like it when I tell her we already have one in all our cloudwatch logs.

Thanks - this is along the lines of what I was looking for .