npm is an incredibly handy development tool. Allowing for breaking your projects up into separate modules keeps logic isolated, maintainable and composable – especially when working with a larger team. When working with proprietary software, we can supply specific URLs in the package to lock down permissions and keep the code out of the public npm registry. However, this can cause a problem when working with portable docker images as the git clone will fail due to a missing id_rsa.
The solution we’re using is quite simple. Provide an ssh id_rsa file to authorize the clone. Instead of using your personal id_rsa, it’s much more appropriate to create one specific for the application and then add the id_rsa.pub as an authorized deploy hook in your git provider. This way you don’t have someone’s actual id_rsa floating around in repositories. Here are the steps:
The past few days I’ve been working a lot with Docker. As with many powerful tools, there are quite a few ways to get the job done. The most esoteric of them being how to persist data within Docker’s containers. From bind-mounting directories to your local system, to spinning up containers with only one purpose in life – storage. Here I’m going to be discussing and experimenting with a slightly different way of handling the issue: Controlled Persistence.
So you just finished developing your node.js application and you’re ready for the world to use it. Congrats. Now it’s time to decide how to host the application. In many cases you would use a turnkey cloud solution like Heroku, OpenShift, or AppFog. These are great services, but what if you want to keep this in-house or you don’t want to shell out the dough for each resource separately? These costs can really add up, even with a non-resource intensive application. Today I’m going to talk about a production-ready boilerplate stack for serving node.js applications from a bare Linux (Ubuntu distro) install.
connect-static2x is middleware identical to connect’s native static() middleware except for the fact that it enables support for image resizing on the fly. After an image is processed, it’s saved in the same directory as the original so the next request is cached.