Showing posts with label terminology. Show all posts
Showing posts with label terminology. Show all posts

Monday, May 25, 2020

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:


Friday, December 6, 2019

Episode #6 - Tools - Git from Asheville-NC

Episode #6 - Tools - Git from Asheville-NC
--------------------------------------------------------------

Where I am podcasting from - Asheville, NC

Target Audience - Technology resources that are new to development or to this tool in particular

SCM description

Git description

Git terminology
-init - Create a new repository (from empty dir or existing source folders).

-config - Set the user.name and user.email config settings for the current user.

-origin - This indicates the starting point of the current branch.

-remote - This indicates where the push command will try to send your changes on the remote system.

-branch - This is an isolated work area for you to make your changes.

-types of branches - master, develop, development, feature, release, hotfix.

-checkout - This is the act of copying the selected branch to a working area where you can make your changes.

-local branch - A branch that is created on your local machine from the remote source.  It can be a new branch created locally that you will then commit and push to the remote.

-status - This command shows the current status of any files in your local workspace that have been modified, staged for commit, ready to push to the remote.....or any errors.

-add - This command readies your modified files to commit.  It is typically used when you create new un-committed files that are not currentlyin git.

-commit - This is the act of telling git that you want to copy your modified files to the branch on your local machine that you have checked out.  You will still need to issue a push command to send the changes to the branch on the remote server.

-commit message - always add a descriptive message of what changes were made and why.  It is useful to put any reference ticket number from your issue tracking system in the commit message.

-merge - This is the act of combining two branches that have different sets of code.  It is done automatically if there are no conflicts.

-merge conflict - This occurs when the same file is modified by two or more developers and their changes involve the same lines of code in the files.

-diff - This is a utility that can be used from the command line to compare two files to display the conflicting differences.

-pull requests - The act of having another developer or team lead review your changes before it is merged into another branch.

-push - This command will copy our changes from your local branch to the remote branch as long as there are no conflicts.  This conflict check can be over-ridden with a command flag.

-pull - This is the command that will pull all the up-to-date information from git regarding your source code respository (branches, tags, etc.)

-clone - This is the act of copying a remote repositort to another workspace where you can make your modifications in isolation from other developers.

-fork - This command allows you to create a copy of a repository that you will not be merging back into the remote for some time (or in certain cases, not at all).

-tags - This is a command line utility that allows you to mark certain sets of files with an identifying tag (numeric, alpha-numeric, or alphabetic).

-branching methodology - This is the decision made by your team on how you will handle parallel development that will involve merging your code from branch to branch before you finally promote it to production (master).

-gitFlow - A commonly used branching methodology.

-log - This command line utility can be used to view changes to a file or set of files.

-revert - This command is used to undo a commit.

-reset - This command is used when you wish to discard all your local changes and revert back to the latest on the remote server. It is not recommended if you follow your branching methodology.

Wednesday, November 27, 2019

Episode #2 - What does DevOps mean to you

Episode 2 - What does devops mean to you?
----------------------------------------------------------------------
DevOps is the union of people, process, and technology to continually provide value to customers.

Teams that adopt DevOps culture, practices, and tools become high-performing....building better applications..... faster...... for greater customer value.

The true meaning of DevOps is all about delivering continuous value to customers.

I did a quick google search and found 10-15 well known websites (some are vendor sites) that each had a slightly different definition but they all revolve around people, process and culture.

Tools are a part of it but the people need to have the desire to achieve the goal and the processes should enable the people to do that.

It's many things
-culture
-mindset
-tooling and process


summary
-------
Some say it is a combination of people, process, culture.

set of processes that allow us to deliver and support software more efficiently.

Developers throw it over the wall.

Operations can't stand devs that do that and they then have to get creative to support it.

*** Looking back over these show notes, I see that I have used the word value a lot.  That is because, in my opinion, that is what DevOps is all about....Customer value.

24 – Tools - Docker

     Date: 6/8/2020 Guests: None Welcome and greetings Recap of last episode In our last episode we contrasted a few different container man...