The post Courses (I am no longer LFW) appeared first on My Blog.

The post Time to brag appeared first on My Blog.

Ticketing/Tracking system – The record of what to do and what was done.

Source Code – The code that runs and the tests that validate it.

Environments and Configuration – The hardware and software that delivers your product. This might consist of even more code and lots of data needed by everything else to do its job.

Monitoring/Alerting – The real time or near-time data indicating the performance and health of your systems.

Document Store – The long term store of data that doesn’t fit anywhere else. Think Atlassian Confluence or a Wiki.

There will be a single source of truth for everything and everything needs to be linked to everything else. What do I mean by this?

If a developer is asked to do something, whether it is to add a new feature or fix a bug, their first response should always be: “Have you filed a ticket?” The ticket will not only track the record of the work but it will contain links to the merge request / pull request (MR/PR) and whatever design documents were generated in the Document Store. The MR/PR should generate both automated tests and automated builds. These should generate another ticket, although it might not be in the same system as the one tracking developer work. This “build and test” ticket will contain links to the MR/PR, the build results and the test results.

Let’s track what we have so far:

Developer ticket, with links to the Document Store and the MR/PR. The MR/PR will contain links back to the ticket inside the commit message and any documents in the store should also link back to the original developer ticket. We have another ticket with links to build and test results as well as the original MR/PR. So far so good, as everything we’ve generated will never become an island unto itself. We can take any individual piece and reconstruct the entire chain of work and progress.

Now it’s time to get this into production. Another ticket should be generated, with links back to both the developer ticket and the build and test ticket. More often than not, new features will generate new metrics that need to be monitored and new alerts that need to be defined. Ideally, these are kept in source control as well and their MR/PRs are linked in the “Ops ticket” as well. If additional documentation is created in the Document Store around moving the new things into production, those are linked. As new stuff moves from lower “pre-prod” environments, new details are added and tracked.

What we end up with is a system that people in the future can understand and maintain. When the new hire responds to an alert, the links in the alert will contain enough information for her to understand whatever metrics are out-of-line and how to mitigate the issue. If all else fails, she can track down the original MR/PR which will identify which team is responsible for that area of code, even if the original developer hasn’t worked at the organization for quite some time.

I don’t think many experienced people will find these ideas to be novel, but as we move into a future of fully automated CI/CD and things like GitOps, the focus often drifts into just getting everything working and the attention to how everything should be traceable falls into the TODO bucket.

The post The Operations HOWTO appeared first on My Blog.

With VirtualBox Paravirtualization set to Hyper-V

The same test with Paravirtualization set to KVM

The “test” is simply “openssl speed” which by all accounts is the World’s Hokiest Benchmark, but it does solely focus on CPU (crypto is mainly math) and is installed on essentially every Linux host.

The post VirtualBox in Windows 10 – Hyper-V vs KVM appeared first on My Blog.

Fortunately, there are lots of much, much better alternatives. The one I chose was KodeKloud. I have heard of alternative sites like A Cloud Guru but as I haven’t had any personal experience with them, I can’t really say anything about the quality. I have had people tell me they think A Cloud Guru is pretty great. I went with KodeKloud for two reasons, the first of which is that they have some courses available for free for you to check them out. AFAIK, there is nothing “limited” about the free courses; you get to do hands-on labs and you get a certificate of completion at the end. I took their Introduction to Docker course (some of which was review) and was impressed, but not enough to pay for it. What tipped me over the edge was The Free Week. Sorry, it’s already over, but they had a week at the end of April 2023 where you had access to their entire catalog. It was great. For a grand total of $0 I went through Kubernetes for the Absolute Beginner and got a good way through their Certified Kubernetes Administrator course. A word of advice, if you are going to take their CKA course, skip the Absolute Beginner course as all the material is covered in more depth in the CKA course. Additionally, if you’ve taken the edx course, the absolute beginner course will be redundant as well. What can I say, I’m a completionist.

I did say I got through a big chunk of their CKA course. I was happy enough with the material that I stuck a crowbar in my wallet and started paying on a monthly basis. I chose the “Standard” plan, as I like to build my own playgrounds and the cost is significantly higher for the Premium option. As of writing this, I have just completed the CKA course. Huzzah for me.

I don’t think anything is perfect and I do have some quibbles about the courses I’ve taken so far. The notes and references you get from the videos are just raw dumps of the presentations, so they aren’t particularly valuable as references. In my opinion, they need to spend more time on authentication, authorization and RBAC. The labs occasionally have “availability” issues, but nothing to really complain about. The troubleshooting labs rely far too much on monkeying with configuration files that (in my opinion) will never ever get touched so I don’t think they are entirely realistic. Some of the lab questions can be vaguely worded or rely on techniques that weren’t covered in the video lectures. But these issues are not endemic. They do put a good emphasis on using the K8S docs to work in problems in the labs, which is apparently the only resource available to you during the CKA exam itself. But it boggles my mind how they completely ignore “kubectl explain”. It’s not even mentioned once.

Finally, I cannot stress enough you absolutely MUST install minikube and DO STUFF on your own. Do not rely on any single source for your knowledge. A quick google will get you many free (and legal) links to recently published books on Kubernetes. Get an invite for Google Bard and ask it all the questions that you come up with during the lectures. But don’t use it as a crutch, especially during the labs.

The post edx Kubernetes training is Not Great appeared first on My Blog.

https://hub.docker.com/r/dpage/pgadmin4 which is the official image for pgAdmin

and

https://www.pgadmin.org/docs/pgadmin4/latest/container_deployment.html which gives an overview of deploying the container.

I’ve discovered you can completely remove the “adminer” stanza from docker-compose.yaml. Here’s what worked for me:

version: '3.1'

services:

  db:
    image: postgres
    restart: always
    environment:
      POSTGRES_PASSWORD: change_me
    volumes:
      - /home/drosser/fun/python-api-course/postgresql-docker/pg-data:/var/lib/postgresql/data
    ports:
      - 5432:5432

  pgadmin:
    image: dpage/pgadmin4:7
    environment:
      PGADMIN_DEFAULT_EMAIL: change_me@somedomain.zzz
      PGADMIN_DEFAULT_PASSWORD: change_me
      PGADMIN_LISTEN_PORT: 5050
    volumes:
      - /home/drosser/fun/python-api-course/postgresql-docker/pg-admin:/var/lib/pgadmin
    ports:
      - 5050:5050

After the containers have started, head to http://127.0.0.1:5050. Of course, this setup is completely without TLS (an SSL cert) and shouldn’t be used to serve pgAdmin to anyone other than the local host!

The post pgAdmin4 in a container appeared first on My Blog.

To do any meaningful coding, eventually you will have to move on from SQLite and work directly with a “Real Database”. I don’t have anything against, MySQL or MariaDB but I’ve always reached for PostgreSQL first. Unfortunately, many tutorials or videos will recommend you install PostgreSQL to learn how to use it. Don’t do that.

Run it in a Docker container. Sounds simple, but the devil is in the details. Well, I have created a docker-compose.yaml file which should have most of the details to give you a working and persistent database.

$ cat docker-compose.yaml
# Use postgres/example user/password credentials
version: '3.1'

services:

  db:
    image: postgres
    restart: always
    environment:
      POSTGRES_PASSWORD: <change_me_to_something_secure>
    volumes:
      - /<path_on_local_filesystem>:/var/lib/postgresql/data
    ports:
      - 5432:5432

  adminer:
    image: adminer
    restart: always
    ports:
      - 8080:8080

As of writing this, the most recent version of PostgreSQL is 15. If you want a specific version of PostgreSQL, check the full documentation for the image at: https://github.com/docker-library/docs/blob/master/postgres/README.md

You’ll notice that the most recent “Docker image” of PostgreSQL creates TWO running containers, the “adminer” container is a small web-gui running locally at http://127.0.0.1:8080. I have not investigated whether or not you can turn it off if desired…

At this point, you can use a local “psql” client to connect, but unfortunately the version provided by my OS is far behind.

$ psql -h localhost -U postgres
Password for user postgres:
psql (12.14 (Ubuntu 12.14-0ubuntu0.20.04.1), server 15.2 (Debian 15.2-1.pgdg110+1))
WARNING: psql major version 12, server major version 15.
         Some psql features might not work.

EDIT – You can install a PostgreSQL “psql” client at release 15 for Ubuntu by adding the PostgreSQL apt repository. Directions are at https://www.postgresql.org/download/linux/ubuntu/

To use “psql” inside the container.

# Just shell into the container
docker exec -it postgresql-docker-db-1 bash
# when inside
psql -U postgres

Finally, if you want an even easier way to run PostgreSQL and don’t mind it living in “the cloud” instead of your desktop, simply head to https://railway.app/new

The post Don’t install PostgreSQL appeared first on My Blog.

The post Running Python Scripts in Docker appeared first on My Blog.

The Oracle docs for this (and more) are at https://docs.oracle.com/en-us/iaas/Content/API/Concepts/apisigningkey.htm but I have tried to make the API key creation as simple as possible.

Create an API key

After logging in at the top right of the landing page  you can see a generic user outline which you can click on to drop down a menu.

Select “My Profile”. In the next window select “API Keys” from the “Resources” menu on the left side of the screen.

Under “API keys” click the “Add API key” button. A slider sub-window will open from the right. Select “Download private key”. Don’t try to use your own SSH key as these must be in “pem” file format.

Depending on how your browser is configured, a file browser window will open allowing you to choose where to save the pem file. Select “Add” at the bottom of the slide-out window.

A pop-open window will open. Follow the instructions to create the “~/.oci/config” file.

With the above steps completed, you should now be able to follow the Oracle documentation QuickStart to install the OCI Command Line Interface (CLI) at https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm#Quickstart but do not follow the instructions for “Setting up the Configuration File” as we have already completed that here. Finally, you can start with the CLI Getting Started doc at https://docs.oracle.com/en-us/iaas/Content/GSG/Tasks/gettingstartedwiththeCLI.htm but you should be able to run the following and get a JSON return.

$ oci os ns get

{

  “data”: “<redacted>”

}

The post OCI initial setup appeared first on My Blog.

I Intend to add more details with getting up and running on Oracle Cloud Infrastructure (I guess they need another word for their Three Letter Acronym of OCI) as I get more familiar with it.

The post Oracle’s Free Cloud Resources appeared first on My Blog.