Dendory Capital - Blog

Moving your workloads to the cloud can bring a lot of benefits, but creating a design document should be done way before you begin spinning up virtual machines in Amazon or Azure. You need a plan, otherwise you end up creating a solution that may not match the problem you’re trying to solve. But what does a cloud design look like? Here’s my take on it with a simple template you can reuse any time you want to move an application or workflow process to the cloud. Business objectives The first step is to define your objectives. This shouldn’t be an in-depth technical discussion, instead it should be a high level overview of a paragraph or so, describing what the design aims to accomplish. For example, maybe you’re trying to cut costs by having your workload in the cloud rather than on-premise. Maybe you experienced some reliability or scalability issues and you want to take advantage of the cloud’s natural advantages when it comes to robust infrastructure. Or maybe you wa

As we move to a more automated system, with scripts, templates and playbooks containing all the deployment information for both infrastructure and code, handling secrets can become challenging. This is especially true when deploying into the cloud, where everything is done through the Internet and you need to ensure your keys, passwords, secrets and other parameters don’t show up in plain text in your code repositories. To solve this issue, Amazon introduced the concept of a Parameters Store as part of its Systems Manager page. This can be used to store key/value pairs for free, of up to 4KB in length. They can also be encrypted using a KMS key, and retrieved by your code or through the command line. All you need is the right IAM permission, it doesn’t need to be tied to a SSM managed instance. Creating our parameter To create a parameter manually, log into your AWS console and go to the SSM page. Under the Parameters section, click on Add parameter . There, you can

A while back I wrote a quick article about how to run Guacamole in a Docker container. By using a docker-compose file and containers, it’s really easy to set a web based access to your computing resources. However, there are a few things you may want to do to secure access to your Guacamole site. After all, this portal grants RDP or SSH access to servers, and should be kept as secure as those protocols. Redirecting the main page One of the lines from the compose file was redirecting the main index file to a local one. The point here is to disable the default Tomcat website from showing up on your server if you go to http://server-name/ instead of http://server-name/guacamole/. If you want to redirect users automatically, you can put this HTML code inside of the /usr/local/tomcat/webapps/ROOT/index.jsp file: <meta http-equiv="refresh" content="0;URL='/guacamole/'"/> Disabling the ‘guacadmin’ user Unless you have a regular need to s