Updating Ubuntu - remember to update AND upgrade

I'm putting this here to remind me ... as I'm old and often forget ...... wassat ?

So I've been doing lots of stuff with Ubuntu recently, including containers, Virtual Servers AND Virtual Machines ...

And I remember to run: -

sudo apt-get update

but then wonder why my packages don't get ... updated !

It's simple ... I've run the update which effectively refreshes the list of packages available .... but NOT remembered to run the corollary upgrade process: -

sudo apt-get upgrade -y

which actually performs the update ( or, if you will, upgrade to the updated packages )

I can concatenate this: -

sudo apt-get update && sudo apt-get upgrade -y

which does the job nicely.

If it helps, the auto-complete behaviour of most shells does help ....

Type sudo apt-get and then press the [TAB] key ...

sudo apt-get 

autoclean        build-dep        check            dist-upgrade     dselect-upgrade  purge            source           upgrade          

autoremove       changelog        clean            download         install          remove           update           

If I'm feeling really brave, I'll do this: -

sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade -y

which upgrades the underlying Ubuntu distribution ....

But that's for the brave ! YMMV

Building Docker images for cache

When building a Docker image, it's useful to know that one can avoid the benefit of caching i.e. messages such as this: -


 ---> 790dcbffd65f
Step 2/3 : RUN apt-get update
 ---> Using cache
 ---> a9dadec81fda
Step 3/3 : RUN apt-get upgrade
 ---> Running in b0261d077b68
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...

This is especially useful when attempting to upgrade packages within an image, having previously built an image ...

I appreciate that I could've just deleted the existing images using docker rmi XXXXXXXX but this is a differently easier option: -

docker build --no-cache -t ubuntu -f Dockerfile .

With thanks to this: -

How to force Docker for a clean build of an image

Encrypted container images for container image security at rest

From IBM, we have this: -

Ensure the confidentiality of data and code in container images

This article addresses a remaining security concern for enterprises about the confidentiality of data and code in container images. The primary goal for container image security is to allow the building and distribution of encrypted container images for making them only available to a set of recipients. While others might be able to access these images, they cannot run them or see the confidential data inside them. Container encryption builds on existing cryptography such as Rivest–Shamir–Adleman (RSA), elliptic curve, and Advanced Encryption Standard (AES) encryption technologies.

Encrypted container images for container image security at rest

kaniko - Build Images In Kubernetes

One of my IBM colleagues mentioned Kaniko today

From the site: -

kaniko is a tool to build container images from a Dockerfile, inside a container or Kubernetes cluster.

kaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile completely in userspace. This enables building container images in environments that can't easily or securely run a Docker daemon, such as a standard Kubernetes cluster.

https://github.com/GoogleContainerTools/kaniko

IBM Systems Magazine - Secure Service Containers area Virtual Appliance Framework for Sensitive Workloads

I'm reading, and re-reading, this: -

IBM Systems Magazine - Secure Service Containers area Virtual Appliance Framework for Sensitive Workloads

ready to present on the whole wonderful world of containers on IBM Z at the MainframerZ gig tonight: -

MainframerZ meetup at Mediaocean

One thing led to another: -

LPAR and PR/SM

I love rabbit holes ......

IBM Z defines the future of hybrid cloud

Some useful insights on the ever-moving world of IBM Z, including: -

Tailored Fit Pricing for IBM Z
...
The hallmark of this model is that pricing adjusts with usage, removing the need for complex and restrictive capping, and includes aggressive pricing for growth. The capacity solution, also part of Tailored Fit Pricing, enables clients to mix and match workloads to help maximize use of the full capacity of the platform. At the end of the day, Tailored Fit Pricing is designed to both unlock the full power of the platform and ensure optimal response times and service-level agreements, 24/7.
...

IBM z/OS Container Extensions

...
We’re giving our customers the ability to run Linux on IBM Z Docker container in direct support of z/OS workloads on the same z/OS system.
...

IBM z/OS® Cloud Broker

...
IBM z/OS Cloud Broker is designed such that cloud application developers can provision and deprovision z/OS environments to support the app development cycle.
...

and then there's my very own product-set ( well, not JUST mine, I'm just ONE of the engineers !! ): -

IBM Cloud Hyper Protect

...
Hyper Protect offers a range of on-premises and off-premises deployment choices for extending IBM Z services and data—while balancing performance, availability or security.

Next month, for example, Hyper Protect Database as a Service (DBaaS) will launch. DBaaS will support cloud-native developers by providing both PostgreSQL and MongoDB Enterprise Advanced database choices. It also provides the highest level of commercial data confidentiality for sensitive data, FIPS 140-2 Level 4.2
...


IBM Z defines the future of hybrid cloud

Practising Clean Code in Node.JS

One of my friends hosted a rather excellent Lunch and Learn session today, talking about the benefits of Clean Code, and referenced a book by Robert C. Martin, named: -

Clean Code: A Handbook of Agile Software Craftsmanship

We had a good debate about the advantages and disadvantages of comments in code, given that we can / should have self-describing variable and function names.

The debate continues apace; my personal view is that comment should serve to describe WHY I did something, rather than HOW and WHAT, which absolutely should be self-describing.

I'm thinking about this from the perspective of future support i.e. "Why did Dave do it that way ? Oh, because time was short, or Stack Overflow was down, or the code wasn't intended to live forever" 🤣

Meantime, my friend, Aiden, has written a much more well-informed piece here: -

Practising Clean Code in Node.JS

Go read, and let the debate continue .....