Conor Tolan

ChatGPT Game With Son

2023-01-11T08:56:31+00:00

Draft - Hello, First post of 2023 and its a good one. I am creating a Python based figthing game together with/for my son. With all the discussion of ChatGPT I decided to give it a go and see what it can do.

So the Python that came out looks pretty good to me (I’m no Python expert but I can read and work with it), I ran this in my cmdline and after fixing some spacing issues it worked great. I am honestly impressed. This was my second pass at requesting this game format so I had already learned that I needed to be very specific to get out what I wanted. Initially I got a game with just one attack and no input. It ran but was not fun as a game. It had the working logic which I could have edited manually, but instead I asked more a specific question and got a more specific answer.

class Player:
    def __init__(self, name, health, attack1, attack2, attack3):
        self.name = name
        self.health = health
        self.Attack = {"1": attack1, "2": attack2, "3": attack3}
    def choose_attack(self):
        choice = input(f"{self.name}, choose your attack (1, 2, or 3): ")
        return self.Attack[choice]
    def reduce_health(self, amount):
        self.health -= amount


class Attack:
    def __init__(self, name, damage):
        self.name = name
        self.damage = damage
    def __str__(self):
        return self.name


player1 = Player("Patrick", 100, Attack("Punch", 20), Attack("Kick", 30), Attack("Uppercut", 40))
player2 = Player("Conor", 100, Attack("Slash", 25), Attack("Stab", 35), Attack("Smash", 45))

players = [player1, player2]

while True:
    for player in players:
        print(f"{player.name}'s health: {player.health}")
        attack = player.choose_attack()
        other_player = players[1] if player == players[0] else players[0]
        print(f"{player.name} uses {attack}!")
        other_player.reduce_health(attack.damage)
        if other_player.health <= 0:
            print(f"{other_player.name} has been defeated!")
            exit()

Plays out as

>>> while True:
...     for player in players:
...         print(f"{player.name}'s health: {player.health}")
...         attack = player.choose_attack()
...         other_player = players[1] if player == players[0] else players[0]
...         print(f"{player.name} uses {attack}!")
...         other_player.reduce_health(attack.damage)
...         if other_player.health <= 0:
...             print(f"{other_player.name} has been defeated!")
...             exit()
... 
Patrick's health: 100
Patrick, choose your attack (1, 2, or 3): 2
Patrick uses Kick!
Conor's health: 70
Conor, choose your attack (1, 2, or 3): 3
Conor uses Smash!
Patrick's health: 55
Patrick, choose your attack (1, 2, or 3): 3
Patrick uses Uppercut!
Conor's health: 30
Conor, choose your attack (1, 2, or 3): 2
Conor uses Stab!
Patrick's health: 20
Patrick, choose your attack (1, 2, or 3): 2
Patrick uses Kick!
Conor has been defeated!

Connect to MIG Over IAP tunnel

2022-12-23T08:56:31+00:00

Hello, The most obvious thing to try to do next is to SSH to the VM, but I do not want to be able to connect to these VMs openly over the internet. So I will use Google’s Identity Aware Proxy (IAP) to tunnel into the VMs without having to setup complicated VPN tunnels or opening firewalls to the internet.

Ok, I know I just started writing this up, but it took me three days to get to the bottom of why it wasn’t working. Classic d’uh moment.

Loosely I was following the steps as laid out here in this article, but I was going to do it completely in Terraform code. While it is clearly important to know how to enable service APIs via the UI, for Infrastructure As Code (IAC) you need to know how to do it with the code.

I pulled together these few resource blocks on the first day, no big deal. Applied them with Terraform and expected everything to work like it does in work and like it said it would in the above linked article. Of course it did not work.

I ran the connectivity tests multiple times, I checked again that I had actually see that SSH was open to the whole world by default.

Tried to use the SSH via web browser, all failed to connect. I went back and looked at the created resources and permissions in the TF code. I tried to google what other authentication method I might be using that we do not use in work, but I could not make any progress. I even spun up a fresh VM from a GCP template via the UI incase it was something wrong in my deployment changes from the previous post. In some way I’m glad I didn’t find anything because I means I had followed these steps correctly, but in a more meaningful was I was frustrated that I was not working. That was until I looked again at the default firewall rule. I was going in there to confirm that it was an allow rule and maybe recreate the rule to prove I wasn’t crazy. This is when I saw that the network was configured as default. This didn’t mean anything much except I was not deploying my VMs to the default network and subnets. I had deployed my own network, so the firewall rules for the default network did not apply. I could not SSH because the firewall was not open.

Whether or not now is a good time to write about importing existing resources such as the default network into your TF in order to destroy it, since it is not contained in your IAC, would be an interesting idea. But I’ll leave this post here because it took me way longer than I expected to be able to SSH to my deployed VMs over the IAP tunnel, which once allowed to connect did so as expected, mostly.

Thanks for reading.

Conor

GCP MIG deploy

2022-12-17T08:56:31+00:00

Hello, so I’m thinking about what exactly to deploy, I have a few good ideas from recent work tasks but I would need to develop a few more bits of supporting infrastructure and services. So I am not sure what order to proceed. Today I’ll start with deploying a managed instance group (MIG). If you know AWS you can think of this like an auto-scaling group. Basically it is a set of VMs that are managed as a group to provide highly available services.

Sticking with the theme of this blog, I will deploy the example straight form GCP Cloud foundation fabric, the Compute-MIG bundles a few bits of infrastructure together with minimal TF code and understanding to implement. This method gets you off the ground quickly while you learn the components which work together behind the abstraction.

Here I have copied over the three Terraform resources from the first example of a MIG. I changes the source to be Github and not the relative path in the example. In a real enterprise you will point to your own corporate source control repository. I do not recommend using a local copy of their repo as a relative path.

module "cos-nginx" {
  source = "./modules/cloud-config-container/nginx"
}

module "cos-nginx" {
  source = "github.com/GoogleCloudPlatform/cloud-foundation-fabric//modules/cloud-config-container/nginx"
}

I am actually really glad I came back to look at these examples again because I had missed or overlooked or more likely under appreciated the next example of multiple versions, I am pretty sure this is something I have been looking for to complete a task at work. I’ll cover this when I get to a point of implementing it and I should add a link when the post is created [TODO].

Oh yes, the other thing I changed here is the OS. I have been using Centos mostly so I replaced the boot image, will this work? I don’t know. I hope so.

Ok looks like there is more to update, I replaced the network and subnetwork references but I didn’t get it right the firs time. I needed to reference one of the two subnets I created in my last post

This is the final state I came to after a bit or trial and error. I should probably extract the region into a variable, that would make it better too, but I understand that it is easier to read the code when there are not too many abstractions all at once.

These three resources have been successfully applied to the project.

Thanks for reading.

Conor

Terraform Connected to GCP

2022-11-20T08:56:31+00:00

With Terraform connecting to my GCP account I am able to start focusing on the infrastructure as code part of this project and less on the technical connectivity and setup which have been the focus of the previous posts.

What am I going to deploy? This is a question I have played around with quite a lot, and I think I have a good answer now. Previously I have thought about deploying some sort of app like an example app deployed in a container with all the pipeline bells and whistles that make it a cloud native app. These are quite common out there on the internet and usually come from software engineers who don’t really take the infrastructure as seriously. Yet my experience really is in the infrastructure and not the app side of things. I don’t really care about what application was going to be running and then those projects ran aground because it was not as interesting to me.

So what will I do differently this time, I am aware I started this series of posts without actually going into it. Well now is the time.

I have decided to deploy a mock enterprise datacenter using the GCP Cloud Foundation Fabric. This will give me a fast way to stand up some cool infrastructure and to explore topics that are current and interesting to me. GCP is still a relative newcomer but has scored some top tier customers as enterprises try to balance out their cloud spend and not be totally beholden to AWS.

So let me start now with the VPC Terraform module - for now right out of the documented examples as I don’t have a specific design in mind at this time.

Depending on your familiarity with Terraform, you may spot the source points to github.com directly, in a corporate environment you would fork the code into a local repo. This also allows you to make local copy changes where necessary. At this point I am not referencing a version tag, I am taking the latest. Ideally you will specify the specific version of the module which you have tested. I’ll mature this config in time, but this is ok for now.

I have also improved the Terraform by moving some values into variables.

Variables make the code more reusable, I can define the project name in one location and then easily reference from now on as var.project. In each deployment folder I can then declare what variable may be different between folders such as the region or environment definition [prod] vs [nprd].

Here we also see the use of a terraform.tfvars file, this is an automatically loaded variables file. In contrast to a manually invoked variables file that could be called at run time on the command line.

terraform plan -var=”env=prod” 
or 
terraform plan -var=”env=nprd”

terraform plan -var-file=”prod.tfvars” 
vs 
terraform plan -var-file=”nprd.tfvars”

It all depends on how different you environments are, but you get the idea you can keep the code identical between environments and with switches in the code have different outcomes. In the variables.tf file you can see where I commented out the default value once I moved them into the terraform.tfvars file.

I run Terraform plan command and like the look of it, one VPC and two subnets as expected. So run Terraform apply and answer ‘yes’.

Then Terraform apply throws this error - nothing big just I really am starting from scratch so the API has not been enabled. I followed the link and enabled my billing account. Redo the terraform apply and it works.

So that covered a couple of small technical things but we are also making progress. With a network we can move onto deploying VMs next.

Thanks for reading.

Conor

Connecting Terraform to GCP

2022-11-14T08:56:31+00:00

Next thing I want to get working is Terraform Plan against my GCP project. I quickly swapped out of my blog volume to a Code folder where I will keep my .tf files.

  --volume="C:\Users\ctola\Documents\Blog":"/blog"

  --volume="C:\Users\ctola\Documents\Code":"/code"

I will create a folder for my data-center deployment code. I will distinguish between two types of code, deployment and configuration.

Deployment code is specific to resource deployment, the regions, resource names, specific IPs for VPNs in that region.
Configuration code, is the TF module code which will do the configuration as defined by the deployment code.

You should only have one copy of the configuration code and possibly many copies of the deployment code, each slightly different maybe for different regions or different uses such as Development versus Production.

If I jump in and get ahead of myself and run Terraform plan now with only a skeleton configuration we will see the immediate issue which we need to address. Copying straight from the GCP Terraform documentation here, I will populate my project name in the provider block and I’ll accept the default region configuration. Just as an aside the US Central is a low carbon footprint region, apparently, so its a good default.

Below the provider block I copy paste a compute instance resource block. I will not configure this at all now because I do not expect it to actually work.

With only these two blocks defined you can run Terraform init and Terraform plan. This is not a blog on how to use Terraform but init initialises the folder as a workspace and checks the files for a Terraform configuration, if access to the required modules is not avaialble this is where you will get an error. In my case, there is no issue initialising, but when Terraform tries to connect to GCP there is a permissions error. This makes sense I have not done any authentication yet.

Error: Attempted to load application default credentials since neither `credentials` nor `access_token` was set in the provider block.  No credentials loaded. To use your gcloud credentials, run 'gcloud auth application-default login'.

To use gcloud credentials run ‘gcloud auth application-default login’. Ok so we have not yet added gcloud to the container so now is the time.

I will install gcloud cli as per instructions here, I will copy the commands into the Dockerfile in a new block for readability. Actually, gcloud cli need python, so that needs to be installed too. I’m copying from here for Python.

I know I go on about this often but this is why I use the container approach. Too many times have I wanted to share a tool or piece of automation with a colleague but the pre-requirements are missing and it takes way longer than it should. With a shared team container, you only have to do all this setup once, no issues with missing dependancies or incompatible versions. Yes it is more work if taken in isolation for a single simple task but most thinks I do are not single simple tasks and by dragging out this blog with every step I hope I am helping top make that clearer. It a complex house of cards build up bit by bit relying on all the bits below.

To run gcloud auth it means I need glcoud cli, but also I need Python 3.5-3.9 and for that in CentOS 7 I will need a compatible gcc complier, for that I am best off installing Linux “Development Tools” and so on. After installing Python, to install the gcloud cli it is handy to have wget and then tar to unpack it. I am aware that there are now redundant tools used in commands to do similar things. For example curl and wget or unzip and tar. Why not re-write the example command? Having both of these common tools in my container is going to be useful down the road, so I will add them now.

Right so after working through all that this is my current Dockerfile.

I’ve added commands to get and remove the packages for Python 3.9 and GCloud Cli. I added some more yum package installs to facilitate it. I’ll collapse them into a single line shortly as it saves on container layers but that’s not important here and now.

After the successful build (no I didn’t get it right the first time), then I can run gcloud init in my container. Yay.

Thanks for reading.

Conor

Adding TFEnv to Container

2022-11-12T08:56:31+00:00

Picking up from the end of the last post I needed to include my Git config inside my container so that I do not need to leave the container to use Git. I do this by mounting my .gitconfig file from my laptop into the container where it will be used while running in the container. This is how I get the right mix of disposability and persistence between my laptop and working container environment.

docker run --rm /
  --volume="C:\Users\ctola\Documents\Blog":"/blog" /
  -it docker.io/library/mycontainer:local

docker run --rm /
  --volume="C:\Users\ctola\Documents\Blog":"/blog" /
  --volume="C:/Users/me/.gitconfig":"/root/.gitconfig" /
  -it docker.io/library/mycontainer:local

Again this is why I save this command, I don’t want to get deep into a repo update and then realise I haven’t go whatever setting configured and I need to go set it and lose my flow. This pattern can be use with other file configs too, and you do not need to mount an actual in use file, it could be a specific file that you place in a persistent location just for ease of use. You might have one .ssh config for one project and another in another folder. You would swap between them by changing the one mounted at run time.

Project 1

docker run --rm /
  --volume="C:\Users\ctola\Documents\Blog":"/blog" /
  --volume="C:/Users/me/configs/Project_1/.gitconfig":"/root/.gitconfig" /
  -it docker.io/library/mycontainer:local

Project 2

docker run --rm /
  --volume="C:\Users\ctola\Documents\Blog":"/blog" /
  --volume="C:/Users/me/configs/Project_2/.gitconfig":"/root/.gitconfig" /
  -it docker.io/library/mycontainer:local

Right with that working I want to get Terraform installed. I’m going to take the Dockerfile from yesterday and add some lines. TFEnv, this tool allows quick and easy version switching and handles the installation.

I added a blank line to create a block of lines dedicated to installing and configuring TF. Starting with a ARG line, think of this as a variable. In this variable I will specify the Terraform version number that I want to use, having this defined in one place and then used in a few makes it easier to change in the future. I got these commands straight from the Github linked above.

In the image you can see a commented line which i left in to make the following point. The off the shelf path for the bash profile didn’t match the OS version I have chosen, so the first time I built the container it errored on line 15 because the tfenv binary was not in the path. Hence you can see that I put the full path to get it to build. I tried to source the profile but didn’t work until I realised it was the wrong filename for the bash profile. I added the correct path and it is working now.

I will now remove the last source line and the commented out line. Wether I bother to replace the full path with a short path I dont know, maybe.

Bottom line Terraform is now installed in my container, in a way which makes up upgrading easy in the future.

Thanks for reading.

Conor

VS Code Tips

2022-11-12T08:56:31+00:00

Quick post - this page might become a page of tips.

In VS Code configure a shortcut to “Run Selected Text” in the active terminal.

It is not configured by default and it is a top tip, I use it all the time. Specifically just now I was able to highlight my saved Docker run command in my permanent scratch file and run it. No thinking about what parameters I need or which mount points that are required.

I’ll leave this at this for now and get back to the main post.

Thanks for reading.

Conor

Starting New Project 2022

2022-11-06T08:56:31+00:00

Time to start a new project - frequently while at work after finishing a piece of work it strikes me that this would make a great blog post. While I can’t directly write about what I do at work, I realized I can spin up a similar project on my own time and not risk giving anything away. So here we are.

I am starting now on my new laptop so I really have to start from scratch, took me longer than I wanted this morning just to get the first word. This is a Windows laptop so as you probably know it does not play as well with tech tools as you would think. Having to install and use Git bash just to get use Git, that’s crazy. Hard pass, my preferred approach is to containerize your tools. Create a working environment that you can jump into and always has the required tools.

The benefit to this approach when working within a team is that once you are all on the same container you all get the same work experience. You get to move passed the problems or it working on your computer but not your colleagues.

So I will start at the start. Let’s build a Centos container and start adding the tools that will be used. The process is really simple and worth learning if you have never tried before.

Download and install Visual Studio Code and Docker Desktop if you are trying to follow along. I will admit I installed Git for Windows and was simply not happy with the experience. I played around with Windows Subsystem for Linux (WSL) but again not happy with the experience compared to working with my work Mac. I am not a Mac fanboy - I can’t argue that the cross compatibility with Linux tools though is powerful. Since most of the tech world runs on Linux, if you want to gain experience with the tools you need to be able to run them. This is why I will run a Linux container on my Windows laptop and I do the same on my work Mac.

Wherever you keep you files create a new fold, I call my “Code”. In this I create another folder “Docker_Images” because I want to keep all my docker build related files together (it makes relative path references easier). In this folder I create a file called Dockerfile.

If Visual Studio is a fresh install I recommend turning on “Auto Save” in the settings.

This is the Docker file I created to get me going.

FROM centos:7.9.2009

LABEL maintainer="CTolan@gmail.com"
RUN yum update -y
RUN yum upgrade -y
RUN yum install epel-release -y
RUN yum install git -y

Top line is declaring what base image to start form, this is likely going to be a security hardened image at work, but at home I will use the official image from DockerHub. The label line is not required, but if you are going to do this in work it might be worth keeping for a point of contact. The RUN commands are literally commands that are run building the container the way I want. At this point I want to get Git working, I use Yum commands exactly like I would in a running Centos Virtual Machine. I guess a difference here is that it has to be zero touch, I can not type Y during the install process, I need to pass the “-y” parameter.

The only real addition to this dockerfile versus the off the shelf official image is that I’m adding Git. Sure I could have just run the container docker run --rm -it centos:7 and then installed git manually, but the point here is to setup the processes that’ll add up to a much easier experience when things do get more complicated.

Right so lets build this container. Oh another top tip is to create a permanent scratch file, I have one where I keep all my complex command lines. Working out the correct syntax can take a while, so I like to keep an example of the commands I use so I can quickly use them again in the future. Hence I’ll save this Docker build command.

Docker build -t mycontainer:local .
>>
[+] Building 2.1s (9/10)
 => [internal] load build definition from Dockerfile
 => => transferring dockerfile: 247B
 => [internal] load .dockerignore
 => => transferring context: 2B  
 => [internal] load metadata for docker.io/library/centos:7.9.2009
 => [1/5] FROM docker.io/library/centos:7.9.2009
 => CACHED [2/5] RUN yum update -y  
 => CACHED [3/5] RUN yum upgrade -y
 => CACHED [4/5] RUN yum install epel-release -y
 => CACHED [5/5] RUN yum install git -y  
 => exporting to image 
 => => exporting layers
 => => naming to docker.io/library/mycontainer:local   

In the terminal of Visual Studio Code I navigate to my Docker_Image folder and could type Docker build ., the . denotes current directory (where Docker will find the Dockerfile). In my Docker build command I included -t mycontainer:local to tag the container after building it. I use local to denote I built it locally versus pulled from a build job. I like to tag containers with the build pipeline number if build in Jenkins for example, others use the Git commit hash but I find it easier to find a container build log by Jenkins build number. It makes it easier to tell which build is newer.

If you read the output you can see the RUN commands being executed exactly as they were written in the Dockerfile.

Next I want to run the container and I want to do a few things at once. Looking at the last line of the build output you see the full reference of the container. So that is how I will reference it.

 docker run --rm --volume="C:\Users\me\Documents\Blog":"/blog" -it docker.io/library/mycontainer:local
 [root@139efa6104cc /]# cd blog/
 [root@139efa6104cc blog]# git version
 git version 1.8.3.1
 [root@139efa6104cc blog]#

I want to remove the container when I exit so add --rm.
I want to have an interactive session in the container so add -it
I want to mount my laptop Blog or Code folder so I use --volume="laptop_folder":"mount_point_in_container"

As mentioned I will save this command into my scratch file since I will use it all the time. It drops me into the container shell where I can cd to the blog folder which is in shared with my laptop blog folder. Any file already in this folder on my laptop will be available in the container, and any files created or edited in the container folder will be available on my laptop.

The first step I took was to clone down my github blog repository, so I could start writing this post, so if you are reading this, then it worked. There is more I wanted to get to today - I haven’t even started on the Terraform side of things, but this process is foundational to that work so it is important to get it setup on this new laptop. I might re-write this into a proper project description and a separate container setup article but I needed to get Git working first.

P.S. of course I forgot a couple of steps. I didn’t mount my gitconfig (I don’t have one on this laptop) so my git push didn’t work, I really am starting from scratch. Ugh I really want to publish this so I might have to use git bash after all.

Thanks for reading.

Conor

Monkey Bars Complete

2021-06-07T08:56:31+00:00

Finally I took the time to do a post on the completed monkey bar project. I am very happy with how it worked out. I learned a lot and got to use other skills that I don’t usually get to in my day job.

Compared to the orignal design I think I nailed it. I didn’t do the ladder of bars up between the pillars yet, I need to find a good way to accomplish it. So instead I tied them together with the step. The hammock was a great surprise pay off.

There was a bit in this for me, on the far end is a pull up bar where my feet don’t touch the ground. I am able to hang freely and I’m working on my pull ups. Note that the kids also get to use the bands as a bungee swing - it looks like great fun.

Thanks for reading. Conor

Day 2 vCenter Time

2020-10-15T08:56:31+00:00

As I had hoped it was actually quiet easy to get the vCenter installed and I did infact know what I was doing, mostly. I knew I’d need to get an ISO from VMware for the VCSA, I downloaded that and created a VM before having created a datastore. This is something I’ve really apreciated about the build, all the parts work out of the box. My thanks to those who have gone before and figured all this out. Hat tip to VMware and Intel for making it happen on the product side, so take my money.

Datastore created, I figure 500GB would be enough. Next I went down the wrong path of copying the ISO to the datastore and then I created a new VM and tried to mounth the VCSA ISO. The VM didn’t boot, that’s not what I should be doing. After a bit of documentation reading I realised that I needed to mounth the VCSA ISO locally on my laptop and then open up either CLI installer or the GUI installer. I went with the GUI this time. Ran into a this error when clicking through the setup, its these little things, I didn’t know that for a production setup I’d need a full 500GB minimum for the VCSA. That could be trip up question in an exam for sure. It’d seperate those experienced installing vCenter from those who aren’t.

No big deal for my homelab to go with thin provisioning, so no issue. So we’re off with step one, deploying the vCenter VM to the homelab. Then step two configuring the vCenter appliance and then done. It is deployed and configured with an SSO domain and the config that I suplied via the GUI. Nothing exciting so I’ll not go into detail.

What I love about this is that the vCenter has no awareness of its host or the platform on which is runs. I have my own vCenter now running with no hosts and it has no idea that it is even a vitual machine. In one company we had many vCenters all run in the production environment for the other enviroments (not nested but same idea). The vCenter really is a control plane for the underlying compute layer where the VMs will exist and they are seperated. Sure you might lose all your visability into your environment if you lose your vCenter but you can always answer honestly that there will be no impact to the running workloads when asked in CAB. Logically then next step is to add the host to the vCenter.

Whenever we do this we automate it and so I am enjoying the nuts and bolts feels of having to add this host myself, but it trust me you never want to have to do this for racks and racks of hardware. Maybe this is my appreciation for a handcrafted artifact when I know full well that our society relies on the success of mass production to sustain our world of abundance.

Ohh now it is looking far more familiar, this is the view point I’ve spend way too much of my career. Not entirely sure what I need to do next, I clearly have some patching ahead of me. Ooh maybe I can play with the new Lifecycle Management features of vSphere 7. From what I saw at VMworld this is finally bringing all the pieces together and automated.

Thanks for reading. Conor