Posts written by Sri Rajan
One of the benefits of containers is the promise of portability. The Docker mantra is to build, ship, and run. Containers also promise the ability to, with few changes, move from a developer’s laptop to a production environment and, in the same vein, the ability to move from a data center to the cloud or to many clouds. However, adopting containers alone does not guarantee this. At the core, containers are just a better way of packaging your applications. While they ensure a degree of technical compatibility across many clouds, they don’t ensure complete portability by themselves. In this post, we will look at some of the many considerations from the portability lens.
In this post, we will look at Docker, CoreOS & Fleet and demonstrate how one could use all of them in an application scenario.
In the last several years and with the advent of social coding sites like GitHub, there has been an increasing openness in code sharing. This is great on so many levels as it promotes the open source model, and in general is a nice thing.
One security side effect has been the accidental disclosure of sensitive information in the code that is shared publically. This problem existed before with things like database or SMTP passwords in configuration files but in the world of cloud and API keys this problem increases in its severity.
Whereas database servers were generally well protected and so even accidentally revealing the password was not the worst thing to happen, exposing API keys on public repositories has serious consequences. You have given someone the keys to your whole cloud kingdom. With these keys one can spin up servers, view your data, upload illegal data and the list goes on. Hackers are most likely searching on these repositories for such information.
We recently had a good debate in the Rackspace tech community on this topic and this post tries to present some best practices and also some ways to clean up should it happen.
Error processing input, missing asset: 2013-05-21-cloud-files/cloudfileslogo.png
In Cloud Files, there is no inbuilt way to do aliases or multiple names to the same object. However, after some documentation trolling and speaking to some of our Cloud Files engineers, there is a way to achieve it, although it is not straightforward.
Maintaining hosts files on standard *nix system has been traditionally done by hand. This becomes a challenge as the number of systems grow and this is more true in the Cloud model where you might add/delete servers at a higher rate. One solution would be to use DNS and use a local zone to store your host name to IP mapping. If you are in the automation using Chef world, here is another example on how to automatically generate the host file entries.