22 - Buzzword Alert - Container Basics

Date: 5/25/2020

Guests: None

Welcome and greetings

Recap of last episode

• In the last episode, I discussed my adventure in MacBook Pro purchasing and upgrading. It’s not really a bad experience if you have the right tools, a little know-how, and a little bit of luck.

• Check out the full episode using the following link.

Scott's Spot 5 - Tech Review - Mid-2012 Uni-body MacBook Pro

Summary of this episode

• In this episode, I’m going to discuss everyone’s favorite topic….containers. I’ll discuss what containers are, how they are different from a regular bare metal server or Virtual Machine, and how they can make your application deployments and upgrades easier.

What’s in it for you?

• After listening to this episode, you will be able to discuss containers with confidence, determine if containers are the right fit for your applications, and have the knowledge to begin the process of creating containerized applications.

Episode Content

• What is a container?

  • An object that can be used to hold or transport something.

  • A standardized unit of software – from the Docker website

• Container terminology

  • Container – a running instance of an image

  • Image (or container image) - an application that is coded as a container. A container is basically an instantiated image. There are currently several different formats for container images (Docker, Appc, LXD, etc.). The Open Container Initiative (OCI) is striving to define an industry standard for the image formats.

  • Image Layer – one or more items that have been added to an image configuration. Each update to an Image results in the differences being stored as a new layer in the configuration.

  • Base Image – every container has a base image or O/S that it is built off of. This is the starting point for new containers. There are several different ones to choose from: alpine, tinyOS, etc. Each one has some of the functionality that you would find the full version of an operating system, but not all of it.

  • Registry – contains a list of available images that can be downloaded and instantiated as containers. These can be hosted on-site by a company or they can allow their developers to use external registries. This can cause security concerns as you cannot always determine the security profile of an external image.

  • Repository – this is what you pull from a container registry. A pull command will download all version (tags) of the application hosted in that container image.

    • ex. docker pull abcxyz

      • abcxyz is the repository

      • and individual image would be abcxyz:latest or abcxyz:ver1.1

  • Tag – similar to how tags are used in git to identify a container at a specific point in time.

    • Refers to a specific version of a container image.several

      • abxyz:latest

      • abcxyz:ver1.1

  • Docker – this is a very popular container management system.

  • Dockerfile – this is a configuration file that is used to build a container.

  • Podman – another container management system.

• How does it differ from a Virtual Machine or server?

  • A server is basically what you see is what you get when it comes to memory, cpu and storage. A Server can dual boot, but typically only runs one type of Operating system.

  • A Virtual Machine can have memory, cpu, and storage changed on the fly. A virtual machine doesn’t have its own physical hardware and shares resources with other VMs on the host. It still has its own full copy of the Operating System, so a defined number of VMs can run on a given host.

  • A container shares the system resources with other containers running on the system. It actually uses system level resources so its container OS can be much smaller and more containers can be run on a given host.

• Where do containers run?

  • There are many flavors of containers and depending on how they are architected, they can be run on linux, unix, or windows hosts.

• What can you put in a container?

  • Best practice is that each container should encapsulate a single application.

  • If you have multiple applications, you can put each one in a separate container and open ports between them so that they can communicate.

• What are the benefits of using containers for application development?

  • Its easy to create your dockerfile (or similar manifest) at the same time as your application (they can both share the same source code repository).

  • If you mess up a container in development, you can trash it and create a new one quickly

• What are the benefits of running your “production” applications in a container?

  • Its easy to scale your capacity by quickly spinning up new instances of your application that is running in their own container instance.

  • If one has a problem, you can easily kill it off and then create a new one to replace it. This results in very little downtime unless you are running an orchestration tool to manage your containers.

• What happens when a container has a problem?

  • Like we said, you can easily destroy or freeze the problem container, create a new instance, and then troubleshoot what caused the problem with the original container.

• How do you create a container?

  • First, you can download a container image of the source OS (alpine is an example)

  • Then you create a container by using the “docker run” or similar command.

  • You can then log into the container and manually install and configure all the software that your application needs.

  • Or….you can take the easy route and create a dockerfile that contains all the configuration information that the container manager needs to create and run your container.

• How and when do you choose a third party source (vendor) for your containers?

  • You can use the open source version of the container managers or if you have a high priority application you can opt for the vendor supported route to ensure that there is a lower chance of failure in either the container or the container management system.

Recap of this episode

---

Like me….. Like my podcast…. Please share the link, click on the like, give us a thumbs-up, leave us a review, hit the subscribe button, and tell your friends!

Next Episode: <next_episode_description_here>

Where you can find us!

Direct Messages:

• @cs_everhart on Twitter

• ScottTalksTech group on Facebook

• ScottTalksTech.slack.com

Links to Podcast Providers:

• On Google Podcasts

• On Apple Podcasts

• On Spotify

• On iHeartRadio

• Pandora coming soon

• PodcastAddict – web link not available but podcast is available in the app

• On PodChaser

• On Deezer

• On ListenNotes

• On OverCast

• On CastBox

Episode #13 - Artifact Repositories

Last episode recap

• In the last episode, we discussed the Sarbanes-Oxley law and how it impacts publicly traded companies, what regulatory controls that have to be in place for a company, and what the impact is for non-compliance or fraud.

Summary of this episode

• In this episode, we are going to discuss where you should store your compiled or “built” artifacts. These tools are referred to as binary repositories or artifact repositories. We will discuss the types of repos that you can create, what artifact types you can store and also the security features for each of the tools.

Episode Content

What’s in it for you?

• After listening to this episode, my hope is that you will have a better understanding of what a binary repository is and what it is used for as well as some of the capabilities of 2 of the offerings in the industry.

What is a binary repository?

• A binary repository is simply a place to store your compiled or “built” artifacts. Some people have in the past used shared network drives or a folder on their laptop. These are not optimal solutions since you can accidentally delete single items or the whole folder itself.

What can you put in it?

• There is no limit to the items that can be uploaded to a binary repository. Simple rule of thumb, no un-compiled or un-packaged source code should be uploaded to a binary repo.

What are the types of repositories that you can use?

• Release – release-able artifacts – ready for installation into an environment
• snapshot – used for builds that are done on a set schedule (daily, hourly, etc.)
• dependency – used to hold artifacts that your build will need to complete successfully but may not be readily available from another source.

What are the major binary repositories?

• Sonatype Nexus
• Jfrog Artifactory

What are remote proxies in a binary repository?

• Remote proxies are typically sites hosted internally to your organization that points to an external site. This is usually done to enhance security to sites that you cannot verify that the content has been properly secured. Here are some examples:

• Maven central
• npm
• docker hub
• etc…

What security tools come with the binary repository?

• Nexus Firewall – add-on product (has a cost)
• Jfrog Xray – add-on product (has a cost)

What are some of the similarities of the 2 vendor tools?

• The both allow you to upload various types of artifacts.
• They both have download mechanisms for existing artifacts.
• They both support release and snapshot repos.
• They both can maintain a dependency repo for internal artifacts needed by builds.
• They both support versioning and tagging of artifacts.

What are some of the differences?

• They both store the artifacts in a different way
• They both store metadata in a slightly different method.

What are the pro’s of each tool?

• Nexus has a built in capability around Maven Central since that company maintains Maven Central itself.
• In my experience, Jfrog Artifactory was the first to support all the different flavors of remote proxies, but both currently support the majority.

What are the con’s of each tool?

• Confusing documentation on both parts. I have experienced random documentation updates in the middle of an installation that required that I re-do part of the work I had just completed.

Recap of this episode

• In this episode, we discussed what binary repositories are, what you can store in them, what the similarities are between the products, and some of the differences.

Next Episode: Wyze home automation hardware review

Bonus Episode #1 - 10 Episodes in and still going

They say that the hardest thing about a podcast is getting through the first 10 episodes without giving up.  Well, I made it.  I would like to thank everyone that has taken the time to listen and provide feedback.  And I will say Thank you to all those that listen to my podcast in the future as well.

I would like to take a couple of minutes to summarize some of the things that I have had to do and learn to get this going.

So here goes:
- Here are the things that I have learned by putting together this podcast.

- No matter how educated you think you are there is always something left for you to learn.

- Take broadcasting for example.  I had to learn recording, hardware choices, sound quality, audio editing, marketing and advertising, and pretty much how to speak.

- If you have never recorded yourself and then listened to your voice on playback, try it.  Record at least 5 minutes of yourself talking and then when you listen to the playback you will be amazed at how many so's, and's and um's that you don't realize that you are saying.  I take some of those out in post-edit.....but not all of them.

- I learned all about Audacity, the open source recording and editing software.  I know about half of the features and probably could benefit from about half of those that are left.

- I learned about marketing.  Social media channels, Search Engine Optimization, and how to generate feedback.

So, once again thanks for tuning in and not tuning out.


Next Episode:  Jenkins - Not your everyday butler!

Episode #9 - Tools - BitBucket vs GitHub

BitBucket is Atlassian's offering that encapsulates Git.  They have an entire suite of products that enable end-to-end collaboration.

It has a lot of the same features as GitHUb:
-----------------------------------------------
- It is built on top of Git.
- It is used for source code mgmt.
- It has pull requests to facilitate code reviews.
- It has branching and merging.
- It has forking.
- It has webhooks.

But it also has other features as well:
---------------------------------------
- It is directly integrated with Atlassian's other tools (Jira (task tracking), Confluence (Collaboration), Crowd (LDAP)).
- It provides a tighter structure to its repositories.
- It provides tighter security through it's integration with Crowd.
- It facilitates collaboration through its integration with Jira and Confluence.
- It provides end-to-end tracking when a branch is created from a Jira ticket.

Pros:
-----
- It can be hosted in Atlassian's cloud environment or it can be on-prem at your company.
- It has a high availability Data Center version.
- It has unlimited repositories for free for up to 5 users.
- Is is supposed to have better searching but we have found it lacking in regards to wildcard searches.
- You can import your code from more SCM systems than GitHub.
- Powerful Jira integration can update Jira ticket status on BitBucket commit.
- Offers in-line comments directly in the code review window.
- Integrates directly with Trello.
- Integrates with Slack.
- Better pricing (GitHub private repos can be pricey).
- Powerful ACL thanks to integration with Crowd (think LDAP server with groups).

Cons:
-----
- Smaller community
- Fewer plugins
- Wildcard searches

My Take:
------------
Using the Atlassian suite enables you to have end-to-end tracking of source code changes that starts with the entry of the requirement into a Jira ticket.

Next episode:  CI/CD Basics