131–140 of 180 posts
> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…
Earlier quoted context omitted.
Yeah but if you use bare tools then it’s hard to change them and the interface may differ project to project. If you let the JS developers pick your universal build tool then they’ll want to change it annually because now the old one they loved is “terrible” and some other thing is great and is definitely the way forward. Plus then you’ll need node on every machine that needs to run the build, and probably you’ll wan…
The solution here is to choose a build system that is language agnostic. The most common of these is docker & docker-compose. There's also the Blaze-likes (Pants, Buck, Bazel, Please) that let you hermetically include tools like node inside of the build chain. Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools. When I do `docker build -t ... something`…
For me, that's kinda the point. If (when!) the underlying layers break, I can open up the Makefile and see exactly what was called, without too much abstraction. It's not there to provide complex build options, it's to provide aliases to the commonly used commands in a platform agnostic way.
Most of my make commands are simply aliases for one or more commands, which are often something like `docker run --rm -it project_runner_image some_command`
There's some real problems with Makefiles in the form of tabs as the prefix, running everything as a shell, weird platform specific versions, etc - but I've yet to see anything else which is as small, as universally available, with such a low barrier to entry. Most of the other options I've seen so far (and I'll be the first to admit I haven't looked very hard) seemed to either be overly complex for simple dev setups, or bound to a particular language.
Earlier quoted context omitted.
Do you have an open source Dockerfile that demonstrates this pattern? I've used builder images before, but not multiple.
The relevant search term is "base image" Just remember to have a process to rebuild your base image at least once a month so you pick up latest security fixes etc.
Remember Greenspun's 10th rule? "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Well, there's a kubernetes version, which is that any sufficiently advanced deployment system will ultimately be half assed version of kubernetes.
Including Kubernetes itself!
...back in 2015 ;)
Now I'm completely in favor of hosting anything you can cram into kubernetes in kubernetes, even though kubernetes is more complex than most other infra tools, most of the time there is only one way to do things(configmaps for config, PV allocations for storage etc..) So if you understand kubernetes, it's easier to get the larger picture about the infrastructure even if you know nothing about the application stack.
If you have a relatively simple deployment structure (one big application with 10-20 services), maybe you don't need to add the docker skill to what you're already doing.
If you're in the process of rebuilding your applications and you've decided cloud native is the way to go, then containers are pointless.
I'd argue if you don't have the skills and you don't want to pay someone to do this work full-time, you might put your developers in a position to fail.
Based on my 30+ years of building software, I see containers as a dead end. It may help you out in the short term, prove to your CTO that you're using "well-known" technology, but in the end, cloud native is going to replace everything. And before you say "but we can't be in the cloud," then you should know that cloud-native development like Lambdas can be done on-prem as well.
I'm positive this post will get negative votes. That's fine. I like tilting at windmills.
> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…
Can I ask people who _don't_ use Kubernetes and maybe have architectures built on proprietary cloud services: how do you manage this?
We used to be able clone 400 VMs in 1 hour, sanitize all customer data and refresh a full dev environment from m prod in an hour. TBs of data.
But let's all stand around and claim k8s is not your flavor of the day solution to a very old problem, but one that caries a huge amount of complexity and so much network effry that it scares the pants off most people.
> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…
Most of the issues seem to be with Postgres DB connections, but it makes starting up our backend painfully slow...
> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…
Anyone encountered issues running a docker-compose stack of 5+ containers mostly RoRails apps incl. Postgres on Mac Catalina? Most of the issues seem to be with Postgres DB connections, but it makes starting up our backend painfully slow...
Edit: Some tuning options also exist - https://docs.docker.com/docker-for-mac/osxfs-caching/