Read this case study about using Elastic Beanstalk to launch Docker containers and take our learnings to your workflow. Start here!

Using Elastic Beanstalk to Launch Docker | Inventive Blog

Read this case study about using Elastic Beanstalk to launch Docker containers and take our learnings to your workflow.

I am a big fan of AWS, but I have to admit that I have never been overly fond of their documentation. Over the past week, I had the opportunity to start a new project and decided to try using elastic beanstalk to launch my docker containers from an Elastic Container Repository (ECR – another AWS service.) Along the way, I encountered a couple of hurdles and the purpose of this posting to help others with similar goals to navigate the process with a little more ease.

If you are interested in following this post, I recommend getting Docker, AWS-CLI and the Elastic Beanstalk command line tools installed first.

This was the first hurdle. The aws cli gives you a handy function that is supposed to log your Docker session into the AWS registry, but when I run it as described in the AWS documentation, it fails:

bash> $(aws ecr get-login)
unknown shorthand flag: 'e' in -e
See 'docker login --help'.

Apparently, my version of Docker does not support the email option on login.

bash> $(aws ecr get-login –no-include-email)
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded

The warning looks serious, but the command seems to have logged me in any way.

The next hurdles came here. Elastic Beanstalk (EB) has a handful of different ways for deploying container environments. By far the easiest way I found to deploy something to EB is to use the EB command line tool. You start by running ‘eb init’ which will guide you through the process of setting up a new application or connecting to an existing one. Note that your run ‘eb init’ in a directory that contains files that you want to deploy. The ‘eb init’ command stores the choices you make in the initialization process to a hidden directory (.elasticbeanstalk) and will be used to set preferences for future invocations of the ‘eb’ command.

Once you have set up an application, you need to create an environment. ‘eb create’ will create you an environment, using the files in your local directory.  There are some immediate caveats to this. By default, the eb cli tool is going to zip up your entire current directory and upload it to S3. If you have a Dockerfile, the elastic beanstalk cloud servers will use it to build your container, regardless of whether or not you have a Dockerrun.aws.json file.  If you are wanting to deploy from an AWS ECR image, you must ensure that you create your environment from a directory that has a Dockerrun.aws.json file and NO Dockerfile.

Ready for the next caveat? There are two versions of the Dockerrun.aws.json file. They are not interchangeable. Version 1 is for single container environments and is quite limited. In fact, there is no way to specify environment variables for the container via the version 1 Dockerrun file. If you are like me, you might be tempted to try to use the version 2 Dockerrun file, but it only works for multi-container environments. In my case, the application I was trying to deploy was really quite simple and I did not want to got the path of multiple containers, but I most certainly did not want to bake configuration information into the container. After a lot of searching, I found that there is a way to push environment variables to single-container eb applications – you have to set up a `.ebextensions` directory that contains a ‘.config’ file. The config file format is somewhat less than obvious but is detailed here.

In the end, this is what my final deployment environment looks like for my project that deploys from ECR:

bash> ls -alR
.:
total 17
drwxr-xr-x 1 chris 197609   0 Feb 26 09:32 ./
drwxr-xr-x 1 chris 197609   0 Feb 24 09:46 ../
drwxr-xr-x 1 chris 197609   0 Feb 24 10:44 .ebextensions/
drwxr-xr-x 1 chris 197609   0 Feb 24 10:45 .elasticbeanstalk/
-rw-r--r-- 1 chris 197609 208 Feb 24 10:17 Dockerrun.aws.json

./.ebextensions:
total 9
drwxr-xr-x 1 chris 197609   0 Feb 24 10:44 ./
drwxr-xr-x 1 chris 197609   0 Feb 26 09:32 ../
-rw-r--r-- 1 chris 197609 425 Feb 24 10:44 .config

./.elasticbeanstalk:
total 5
drwxr-xr-x 1 chris 197609   0 Feb 24 10:45 ./
drwxr-xr-x 1 chris 197609   0 Feb 26 09:32 ../
-rw-r--r-- 1 chris 197609 535 Feb 24 10:18 config.yml

bash> cat Dockerrun.aws.json
{
   "AWSEBDockerrunVersion": "1",
   "Image": {
     "Name": "123456789876.dkr.ecr.us-east-2.amazonaws.com/container-name",
     "Update": "true"
   },
   "Ports": [ { "ContainerPort" : 3000 } ]
}

bash> cat .ebextensions/.config
option_settings:
   - option_name: FOO_SETTING
     value: foo
   - option_name: BAR_OPTION
     value: bar

With this directory I can create a new environment that launches a container from the ‘123456789012.dkr.ecr.us-east-2.amazonaws.com/container-name’ image, passing in the FOO_SETTING and BAR_OPTION environment variables. When I need to redeploy, I can just tag a new image with ‘123456789012.dkr.ecr.us-east-2.amazonaws.com/container-name:latest’ and run ‘eb deploy’ in the same directory.

5 Common Coding Mistakes and How to Fix Them

Learn how you can write better and cleaner code by discovering the five most common coding mistakes and how to avoid them. Read more!

5 Common Coding Mistakes and How to Fix Them | Inventive.io

We’ve all been there. You hit compile, you run the program, and everything explodes like an action scene straight out of a cheesy Michael Bay movie. With error messages whizzing by left and right, you ask yourself: Why isn’t this working?

On a bad day, your code works and you don’t know why. On a good day, it works, and you still might not know why.

But no matter what day it is, this could all be avoided. How do you ask? That’s actually a really great question and one that we’re excited to help you answer. 

NEGLECTING TO USE A SOURCE CONTROL SYSTEM

A source control (or version control) system is a system used for the management of files, documents, source code of computer programs, or anything else related to a large collection of information. Whether you’re writing a simple application on your own or collaborating on a large software development project as part of a team, source control is a vital component of the overall development process. 

Source code management systems like Git allow you to track your code changes, view the complete revision history for your code, and go back to earlier versions of a project when needed. You can also easily collaborate on code with your team, isolate your work until it’s ready to go, and quickly troubleshoot issues by identifying who made the changes and what those were. Simply put, source control systems can help streamline the development process and save you from pulling out your hair after realizing you’ve made a huge mistake.  

When programmers build software, they do so based on requirements that are likely to change in the future. Why do these requirements change? Well, the software moves, grooves, and interacts with the real world, which is very dynamic. When these requirements change, developers, who maybe didn’t write the OG version, must incorporate the new updates. In order to do that without the need for their secret stash of emotional support chocolate (anyone else turn to candy in times of stress?), code readability is key!

In order to develop readable source code, we should all ask ourselves: “If I re-read this piece of code in fifteen days or one year, will I be able to understand the abstraction I’ve created?” or even better, “If a programmer who just joined the development team reads my software, will they be able to understand what I’ve written?”

There are many tools and practices that increase the readability of a project, including:

Writing for the “future you” by using readable source code will save you valuable time, resources, and headaches all the while increasing productivity and collaboration. A win-win-win if you ask us.

Every great programmer has written a lot of bad code. A lot. It’s par for the course and a completely normal part of the process. One of the most important things to remember when you’re coding is to be open to changing your code in order to get it to a better state. You do this by learning different and more effective ways to solve problems. 

When lifting weights in the gym, there is a certain correct “form” for each type of exercise. The better your form, the more effective the workout. Code is very similar to that. You should always audit your code and see if you could write it more clearly and effectively. 

It’s okay to make mistakes. Just know that you always want to be thinking about how you can improve your code. 

FORGETTING TO TEST (MANUAL AND AUTOMATED)

Speaking of refusing to change bad code, one easy way to identify that aforementioned bad code is to test, test, test! Sometimes we as developers miss the most obvious errors, or perhaps we know about them but tell ourselves that we’ll “come back to them later.” Every programmer has played this risky game before, but then it’s time to deploy the website or do a demo for a client. The programmer pulls up the brand new site for them only to be greeted by an aggressively bad and ugly-looking server error message. Not ideal. 

That’s where testing comes in. It’s like your BFF that keeps you from looking silly in front of the people who pay you. That said, testing, like your BFF, can be easy to take for granted because it’s always there. We’re here to remind you about the importance of testing and to appreciate the value it provides (oh, and to also tell your best friends thank you because they’re your best friends and they deserve it). 

 So what are the benefits of testing — both manually and automated — and what can it save you and your team? 

For starters, testing can save you hours and hours of debugging. When you have tests that your code needs to pass, you prevent bugs from creeping in. You’ll catch all of the little things like syntax errors and incorrect values that sometimes make it to the next phase of your pipeline. 

Testing also makes you think about your code before or as you write it. This can help you better identify which parameters you should expect, understand why you’re writing the code in a specific way, and learn how you think the user could break the code. By the time you finish a certain task, you’ll know everything about the nuts and bolts behind it. 

Regularly testing your code can also help you write efficient code the first time, give you documentation for the application and keep deployments smooth as a fresh new jar of Jif peanut butter. 

AN EXPECTATION THAT YOU WILL EVENTUALLY FULLY UNDERSTAND ALL ASPECTS OF PROGRAMMING

Joel Spolsky so perfectly coined the term “duct-tape programmer,” which does an amazing job of describing how software is actually built. 

Most people think software is built like a rocketship — expertly designed, crafted, manufactured, and launched without a hitch. It sounds great! In reality, however, building software is more like repairing a speeding go-kart as it races down a hill, using only duct tape and WD40.

It’s a process full of twists and turns, adjustments, and in-the-moment changes. Don’t let unreal expectations of how the world works cloud your judgment or fill your head with doubt. You might have absolutely no idea what you’re doing sometimes. And that’s okay. That just means you’re finding your way. 

Everybody makes mistakes, and coders are no exception. When you’re writing code, paying attention to the small details can help dramatically. Employing smart strategies like using a source control system and writing for the “future you” with crystal-clear readability in mind will pay dividends. As will not being afraid to change bad code, regularly testing the heck out of it, and realizing that coding is an ever-evolving process. Practices like these will not only help to prevent you from making mistakes in the future but will also level up your programming skills. 

And that is what we like to call a blockbuster ending!

We believe anyone can learn how to code if they put in the time and effort. If you’re ready to take the leap, contact us today, and let’s chat about how you take part in Inventive’s Coding Bootcamp! 

4 Optimization Tactics to Eliminate Cloud Waste

Luckily, our team at Inventive has dedicated services to eliminate cloud waste for clients and optimize their cloud foot prints for optimal cloud optimization tactics. Read more!

4 Ways to Eliminate Cloud Waste | Inventive

Luckily, our team at Inventive has dedicated services to eliminate cloud waste for clients and optimize their cloud foot prints for optimal cloud optimization tactics.

HOW TO ELIMINATE CLOUD WASTE – 4 CLOUD OPTIMIZATION TACTICS | INVENTIVE

With cloud service spending projected to grow by 17% in 2020 and reach a spend level of $266.4 billion, it’s clear that the cloud is going to continue to grow in popularity and improve the infrastructure of countless businesses. However, for businesses inexperienced with the cloud it can be easy to overspend on their cloud services; this leads to what is known as cloud waste.   

Unfortunately, for businesses not familiar with diagnosing cloud waste, it can be difficult to determine which of your spend is actually being used to better your business. Luckily, our team at Inventive has dedicated services to eliminate cloud waste for clients and optimize their cloud footprints for optimal performance. Keep reading for a deeper dive into our cloud optimization services! 

No matter if it’s a website or an app that’s running on the cloud, both applications likely present an opportunity for speed improvements. Common optimizations to improve cloud speed include:  

Appropriate storage management, an infrastructure with more power and better utilization metrics, and optimizing the user experience will all lead to improved speeds that you and your customers are sure to notice. To ensure that high-speed is achieved and maintained, consistent monitoring of the cloud infrastructure will ensure new issues are quickly found and diagnosed to prevent them from happening again. Regular monitoring will also create speed improvements over time as issues are consistently found and resolved.

Website and app crashes are so impactful that downtime for popular retailers like Amazon, WalMart, and Home Depot is usually in tomorrow’s news coverage. While your business’ downtime may not make the news (thankfully), the inconvenience it’s sure to cause your customers and internal stakeholders is absolutely worth preventing. On top of the inconvenience, any downtime your app or website experiences is interfering with your bottom line.  

To prevent any cloud downtime, our experts will likely recommend a combination of adopting a multi-cloud environment, improving cloud security, and the addition of CDN services. While the specifics will certainly be prescribed to fit your business’ unique situation, you can rest assured that any improvements in your site or app’s downtime will lead to increased business growth down the line. 

Monitoring cloud system scaling goes in two directions. The first being your current cloud setup might be oversized for your business’ needs which can ultimately lead to significant cloud waste. The size of the cloud infrastructure needed is totally dependent upon the size of your application as well as the amount of traffic it consistently receives. Unfortunately, most businesses don’t take the time to determine their cloud needs, in fact, reports estimate that over $5.3 billion was wasted on oversized resources in 2019.

One of the most common types of overspending we can help eliminate is the use of idle resources. For example, many applications take advantage of non-production environments for development and testing, but those resources are rarely used 24/7. By reducing the number of idle resources used, your business will save big money. 

The second direction cloud system scaling optimization can take is determining if your current infrastructure is too small for your needs. If you continue to notice downtime, the size of your current infrastructure is likely one of the driving factors. Our team will be able to diagnose the actual cloud system size your application needs so you can ensure you’re not overspending and that your customers can access your application at any time. 

Methods to extract private and personal information from websites and apps continue to become more sophisticated, so it’s imperative that you address cloud security as soon as possible. Our team specializes in working with Azure, AWS, and other public cloud vendors. Not only can they `easily recognize security vulnerabilities, but they also know both the quick fixes and long term solutions to address any security or privacy issues. 

One of the most common recommendations our team provides is to authenticate and monitor all application and cloud access, but this is certainly not an all-inclusive approach to cloud security. 

Browse our blog for the latest information and insider tips on everything development, website, software, and marketing related. Start reading now!

Blog - Development, Migration, and Website Tips & Tricks | Inventive

technology

Insights

Work with us!

Tell us a little bit more about your project or idea!