That's really become a docker meme. Please be aware you're sacrificing performance due to not using glibc.
https://link.medium.com/S2z0PtVHQ1
If you're just running a go binary you can use distroless as the base for even smaller images.
Also like the "tags" within the dockerfile for dev and prod - much cleaner than the multi-file solution currently in the repo.
Anything beyond binary size vs shared pages?
Out of curiosity, what sold you on this? Has caching of a docker image been considered in this conclusion as well?
I saved hundreds of MB on the front-end images switching to alpine so I want a little alpine crazy :)
- Serving static files
- Not needing to care about binding your application to a privileged port (below 1024)
- SSL certificate handling
- Hosting several applications on the same IP
For a minimal development setup you might not need it though, depends on what you want to do I guess.
- Serving static files
- Not needing to care about binding your application to a privileged port (below 1024)
- SSL certificate handling
- Hosting several applications on the same IP"
All of this should be handled at a higher level with load balancers doing your SSL termination, and CDN for static files. There's no reason your application server should care about any of that stuff.
Nginx was designed to handle backend services easily and programmers from different background may not be well verse in Golang at the beginning.
There are also dead-simple TLS libraries, some that will even get LE certs automatically.
Reverse Proxy for possible load balancing?
you do know that ports <1000 (http: 80, https: 443) require root, right?
will allow program to bind low numbered ports by non-root user.
Just learned this deploying a new rails app behind caddy2 (which is running as the deploy user I setup).
Basically you should just be able to `docker-compose up` and start hacking at front-end or back-end code and have hot reloading of both _just work_.
I aimed to keep things pretty minimal. With some effort you can swap Redux for Unstated, pick a different component library, swap my api router for gorilla mux, whatever you want.
Happy to make changes based on feedback. I'm _sure_ this could be improved with more eyes on it.
Enjoy :)
Postres
Nginx
Golang
React
So .. nope! :)
Also on Windows and Mac Docker user virtual machines with worse performance.
It is OK to install Docker on a throwaway VPS, or in office, but not on your own machine.
Instead of this poor designed technology it is better to use portable programs (which can be downloaded in binary form to avoid compilation) and collection of bash scripts. Then you won't have to install the aforementioned proprietary daemon.
Personally, my issue with PRNGL is that it makes me think it has something to do with random numbers (PRNG should make most think of pseudo random number generator). The same argument could of course validly be made by someone about PNG being a common acronym too, but for some reason PNGR doesn’t make me immediately think it has to do with image formats, where as PRNGL does make me think random numbers. My own mental biases are likely a factor there.
I actually made this over a year ago, and just this week updated all the deps in order to make it public.
There were thankfully few breaking changes, though I did burn like an hour debugging a weird dependency that wasn't compatible with golang 1.13 modules. So it goes!
So I guess only a slight PITA so far haha
For example, my latest project has a React frontend. I’ll incorporate that back into my cookiecutter after I’ve worked out various issues.
[1] https://twitter.com/rob_pike/status/886054143235719169?lang=...
Thankfully it's a one word change :)
The situations you stand up a container infrastructure these days you usually always already have a cloud load balancer like an ALB in AWS in front of it.
I'm definitely going to have a close look and migrate most of the components over. Thanks!
Created a couple GitHub issues for you with ideas to make this project even better :)
