My organization, Universal Layer LLC, today open sourced our Docker and Shards configuration for running Crystal and Amber in a production environment.
The image is based on Docker’s latest debian:stable tag. It pulls the latest testing and working version of Crystal and Amber with our application. We included our configuration for how OpenVPN runs inside a Docker container including information on why it should be disabled in production (privileged containers can take over the host if compromised).
We run Amber as a less privileged user in the event someone finds a remote code execution vulnerability to make it harder to escape the container and damage the host operating system and its configuration.
Some improvements are probably needed to our shard.yml file, we choose to use commit locking rather than relying on the built-in versioning with shards after some recent conflicts that occurred due to issues that occurred with Crystal-DB and Micrate which were frustrating. We also are nervous about trusting that the version will be properly bumped by shard maintainers. With NPM and Ruby Gems you have to publish a new package and bump the version number, with GitHub you can make changes without bumping the number and this includes breaking changes. This isn’t a risk we want to take so our team decided the best option for us is to block any change through the commit locking system that has not been reviewed and tested to work okay with our code. The drawback is it takes longer before we can access the newest features in Crystal and our Shards but we are willing to accept that being it gives us more stability and protects our workflows. And of course this is much better than going into Gitter chats paniced and asking for help which may or may not have a workaround.
We appreciate any feedback the community has to offer on how this could be improved 