26 September, 2020

Back to learning about Docker

A few months ago, I started learning about Docker. I got derailed with work projects and personal projects. Now that I have a bit of time, I want to get back to learning about Docker. 
I came across the book "Learn Docker in a Month of Lunches" by Elton Stoneman. Elton is putting a YouTube video each workday.

Day 1 - Understanding Docker and running Hello, World

Docker Commands covered in "Learn Docker in a Month of Lunches: Day 1"
  • docker version
  • docker-compose version
  • docker container run {name of image}
  • docker container run --interactive --tty {name of a image}
  • docker container ls
  • docker container top {container id}
  • docker container logs {container id}
  • docker container inspect {container id}
  • docker container ls --all
  • docker container run --detach --publish {local port:container port} {name of a image}
  • docker container status {container id}
  • docker container rm --force $(docker container ls --all --quite)

Notes from Day 1

  • The Docker Engine is the thing that runs the containers.
  • Container wraps the application and has resources that the container can access.
  • Containers are like a virtual environment in concept. One major difference is the container relies on the hosting machine's resources.
  • Containers stop automatically when the code in the container stops.
  • The Docker CLI can be configured to run against a local docker server or against a remote docker server

Day 2 - Building your own Docker images

Docker Commands covered in "Learn Docker in a Month of Lunches: 02"
  • docker image pull {name of image}
  • docker container run -d --name {name I want the container called} {name of image}
  • docker container logs {name of image}
  • docker container -rm {name of image}
  • docker container run --end {key=value pair} {name of image}
  • docker image build --tag {name} .
  • docker image ls
  • docker image history {image name}
  • docker system df

Notes from Day 2

  • Dockerfile contains the steps needed to build a Docker image. This kind of like install instructions or a runbook.
  • Docker commands follow a pattern
    • docker {command} {subcommand} - with Docker 1.13 the CLI was restructured
  • We talk about an image as a singular thing. An image is built up of many layers or parts. The images parts can be shared among other images.
  • Dockerfile
    • Dockerfile commands are capitalized (ie FROM, ENV, WORKDIR)
    • FROM line is required and is first-line
    • WORKDIR creates a working directory
    • CMD is the startup command for a container
  • The size listed from the command 'docker image ls' is the logical size.
  • A good practice is to structure the Dockerfile in such a way that the cache is used. This helps reduce the amount of time it takes to rebuild an image. 
    • The build process creates a hash for each step in the Dockerfile. This hash is used to help determine if that step needs to be rebuilt. Once the build encounters a step that needs to be rebuilt then all steps from that point to the last step will be rebuilt.
    • Put the commands that are least likely to change first

Day 3 - Packaging apps from source code into Docker images


Docker commands covered in "Learn Docker in a Month of Lunches: 03"
  • docker image build -t { name of image } .
  • docker container run { name of image }
  • docker network create { name of network }
  • docker container run --name { name of container} -d -p { host port }:{ container port } --network { name of network } { name of image }docker co
  • docker image ls -f reference={first image} -f reference={second image}
  • docker system prune

Notes from Day 3

  • Able to run commands inside Dockerfile
    • examples would be expanding zip files, running Windows installers, running a git command
  • Dockerfile can contain multi-stages
    • the final stage should contain only what is needed to run the application
    • the image size can change while the image is building
  • With Docker, it is possible to build an image from source code without having an SDK installed
  • Dockerfile
    • EXPOSE - port the container should listen on
  • Multistage Dockerfiles are important and useful
    • Helps standardize your project across various OS
    • Helps standardize processes across projects. Any project using a Dockerfile basically need two commands to get the project running
      • docker image build
      • docker container run
    • The use of layers within an image reduces the amount of time spent in rebuilding images
      • The first time an image is built all the layers need to be pulled, processed, and cached. After the first build, the cached layers can be used.
        • The order of the commands in the Dockerfile is important
      • The use of layers and cache comes at the expensive of hard drive space
        • Docker doesn't auto clean the cache
    • Separates the build & package tools from what is needed for deployment
  • Within a multistage Dockerfile, the steps in each stage should be organized so the steps change slowly or whose results are not like to change goes first.
    • You can only optimize so far. If one step relies on the results of a previous step then the steps must appear in that order.
      • An example would be the run command 


Resources





Fighting with the first layer

Recently, three events happened in a row that is leaving me with the problem of getting the first layer of my 3D prints to stick. The PLA filament that I was using ran out. An update to OctoPrint went sour, resulting in a rebuild. Lastly, I updated the version Cura I am using. 

I have tried several ways to get the print to stick. First was flipping the glass bed over. I have gone through the bed leveling process (both manual and automatic) several times. According to Bed Visualizer, I am close. In Cura, I have tweaked the 'Initial Layer Height' to 0.1 and the 'Build Plate Temperature' to 65C. The results I have gotten so far are either the filament doesn't stick or after a few layers, the edges start to curl and pull away from the bed. 

My next set of changes involved using a glue stick and switching from a skirt to a brim. I was able to get a 'CHEP Calibration Cube' to print. The print popped right of the bed. Closer inspection of the print revealed that the first layer is under extruded and the edges of the print pulled away from the bed. The top of the print (last layer) looks like the nozzle dig in a little (over extrusion).

I compared the latest print to prints from the previous roll of filament. The first layer on the previous filament is much thicker.

Possible Options

  • Make sure the bed is level
    • Good prints start with a level bed. 
    • Did this 4 times earlier in the day
  • Reduce the print speed for the first layer
    • It idea behind the slower print speed is to give the filament time to flow out of the nozzle into place and harden.
    • the current setting is 25 mm/s. This seems reasonable speed. I will skip with option
  • Increase the height of the first layer 
    • From what I have read, increasing the initial layer height can reduce the backpressure on the filament which should let the filament flow out a little easier.
  • Increase the extrusion amount for the first layer
    • This should force a bit more filament out. There is a possibility of the print suffering from an elephant's foot. It could also increase the backpressure on the filament.
  • Increase the extruder temperature
    • A little more heat could allow the filament to flow a little easier. 
  • Check the filament diameter setting
    • The filament size is 1.75 in the settings. 
    • Checked the nozzle diameter at the same time. 

Setting up for the next test print

Reprinting the CHEP Calibration Cube. Changed the initial layer height from 0.1 to 0.12. Changed printing temperature from 195C to 200C. Used the glue stick on the bed. 

Results

The print stuck to the bed a lot better. The first layer doesn't have as many defects and imperfections. I can clearly see a space between each line the makes up the first layer. This looks under extruded.

It seems this filament like the 200C. 

Setting up for the next test print

Reprinting the CHEP Calibration Cube. Changed the initial layer height from 0.12 to 0.18. Used the glue stick again. 

Results

There is even less under extrusion with the first layer. 

Setting up for the next test print

This time, I going to print the CHEP Calibration Cube, one of the tolerance tests from Makers Muse, and a few models of my own design (drop ceiling clip). Changed the initial layer height from 0.18 to 0.20. Changed from brim to skirt. Used the glue stick on the bed.

Results

I canceled the print just as the 3rd layer was starting. One of the models was not sticking to the bed. The first layer is under extruded. 

Setting up for the next test print

Just printing the CHEP Calibration Cube. Changed the initial layer flow from 100% to 102%. Wiped the bed down with Isopropyl Alcohol. Used the glue stick.

Results

The print was really stuck down. I have to use a putty knife to get the print free. The individual lines that make up the first layer are a little fatter and there is still a bit of space between the lines. 

Wrap up

This turned out to be a good learning experience. The lesson of a 'level bed is the starting point' was re-enforced. I learned that the distance between the 'bed and the nozzle', 'how fast the material flows out of the nozzle', and 'type of bed surface' all impact each other.  


18 September, 2020

OctoPrint Reinstall

From the OctoPrint web site, I downloaded a new version of OctoPi 0.17.0 image. Used gparted to wipe out all the partitions on an SD card. Next came flashing the OctoPi image to the SD card using Etcher.

Modified the octopi-wpa-supplicant.txt on the boot drive with my network credentials and modified the country info

After placing the SD card back in the Pi, I powered the device up and waited 5 minutes. I found the IP address of the Pi then opened a terminal window and started an SSH session to the Pi. 

From the command line on the Pi, I ran the command 'sudo raspi-config'. I changed the Password, changed the Timezone, and updated to the latest version. For good measure, I rebooted the Pi.

Once OctoPi was up and running, I opened the URL to the local version of OctoPi, I went through the standard setup screens. After another few minutes, I was prompted to updated OctoPrint to 1.4.2.

Once the OctoPrint finished updating to the latest version and rebooted. It was time to get some plugins.

Plugins

  • Bed Visualizer
    • Ran multiple times and made small adjustments between each run. 
  • EEPROM Marlin Editor
  • Navbar Temp
  • Octolapse 
    • Starting off with this disabled. I will need to come back later to config and enable. 
  • Octoslack 
  • Themeify
    •  Applied the settings from Teaching Tech
    • Added a new style. Selector '.navbar-text', CSS-Rule 'color' Value '#667cea'
  •  
In Cura, set up a connection to OctoPrint. The set up is found in Preferences -> Printers -> Select the printer -> Connect OctoPrint button.

 


14 September, 2020

Upgrade to Cura 4.7.1 and Upgrade of OctoPrint to Python3

Cura

Today, I made the jump from Cura 4.62 to Cura 4.7.1. In reviewing the release notes, for Cura 4.7.0 there were a lot of updates. I should have updated to Cura 4.7.0 earlier. 

There are some items in Cura 4.7.0 that I am looking forward to playing with or will make using the tool a little easier. 

  • Rotation widgets
  • Moved tree-support from experimental to normal settings
  • Adjust initial layer horizontal expansion
  • Allow a g-code to be inserted before or after pausing
Cura 4.7.1 contains a small list of bug fixes. 
 

OctoPrint

When I fired up OctoPrint today, I was greeted with the notice 'Upgrade your OctoPrint install to Python3!' After reading the blog post, I couldn't see a reason not to update. I open a SSH session to my Rasberry PI running OctoPrint and ran the commands from the article. It took a bit of time for everything to download and install.

There are some messages from the updated that will need to be researched or addressed at a later day. 

After rebooting the Raspberry Pi, I am now getting a message that 'The OctoPrint server is currently not running'. When I SSH to the Raspberry Pi, the message 'OctoPrint version : unknown' and 'OctoPi version : 0.17.0' is now displaying.

After a bit of thought, I am just going to rebuild the OctoPrint installation.

13 September, 2020

Updating the version of Docker on my primary machine

I noticed that the version of Docker that I am running a little behind the current stable version. I am thinking it is time to update.

After reading the 'Install Docker Engine on Ubuntu' page, I needed to make a few changes to my system.

My first step was to remove the source 'https://download.docker.com/linux/ubuntu disco stable' from sources. It was simple to follow the steps.

Ran the following commands

  • sudo apt-get remove docker docker-engine docker.io containerd runc
    • This made sure that any older versions were removed from my computer.
  • sudo apt-get update
  • sudo apt-get install \
        apt-transport-https \
        ca-certificates \
        curl \
        gnupg-agent \
        software-properties-common
    • This allows apt to use a repository over HTTPS
  • curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
    • Added the Docker's GPG key
  • sudo apt-key fingerprint 0EBFCD88
    • Verifies that I have key with the correct fingerprint
  • sudo add-apt-repository \
       "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
       $(lsb_release -cs) \
       stable"
    • setup a the stable repository
  • sudo apt-get update
  • sudo apt-get install docker-ce docker-ce-cli containerd.io
    • installed the latest version of Docker Engine and containerd

Challenging myself to learn something new

I have recently set a big challenge for myself. I want to know about Machine Learning . To add to the challenge, I am trying out usin...