Comedy of Errors: Mac gpu dies, no boot screen, Unifi Controller on unselectable MacOS disk

I’m not sure how all these issues occurred at the same time (or at least close enough together to cause issues), but here’s the story:

My Unifi network Controller app is on my 2008 Mac Pro. It has 2 GPUs, the original ATI Radeon HD 2600 XT that supports the Mac boot screen, and a Nvidia 750ti that is a PC card and so doesn’t support the boot screen. The 750ti is my normal gpu, the 2600XT is connected to a smaller monitor that I only use to access the Mac boot screen to switch between Windows 10 and MacOS.

At some point the 2600 XT just stopped working, it doesn’t have any video output from either of the monitor connectors. I’ve pulled it out and reseated it, but it’s just dead. While I was booted in MacOS a couple of days ago I changed the default boot disk to Windows 10 (mistake #1) to access some files from Windows. At that point I started to realize I’d lost a way of getting back into MacOS without a way to get to the boot screen.

Fast forward a few days, I started up my DL380 rack server which I use on a different IP range to the IP range for the rest of the house. I can get to the HP ILO on 10.0.0.2, but I can’t access ESXi which is normally on 10.0.0.3. I can’t get to the Unifi Controller (because it’s on the MacOS disk that I can’t boot) to see what IP that port on the hub has, and running arp -a or using Angry IP scanner is not showing any new IPs getting allocated via DHCP.

My stack of network hubs is under my desk, so getting underneath my desk I realized I’d plugged the DL380 in to the PoE input port and not a network port. While adding another PC to the hub a few weeks back I had moved that port from my 10.x.x.x network back to 192.168.1.x. So now plugging the DL380 network into any other free port on another hub means ESXI still thinks it’s on 10.0.0.3, but I can’t reach it as there’s no route via the port it’s now plugged into.

I need to switch back one of the ports on my Unifi switch back to the 10.x.x.x network, but:

  • I can’t boot my Mac Pro to MacOS because it’s stuck in Windows 10
  • I need to get a replacement Mac GPU that supports the boot screen
  • I can’t switch a port on the Unifi switch back to 10.x.x.x because I can’t access the Unifi controller app
  • I don’t have remote access enabled to my Unifi network
  • I don’t even know what id/pwd I can use to ssh into the Unifi switch

Next steps:

  • Cheap replacement Nvidia GT 120 ordered on ebay for $30.

Summary: What you need to deploy a Docker container to AWS ECS Fargate

In my previous post I walked through a couple of tutorials to deploy a test Docker container to AWS ECS Fargate. As a summary, here’s the various parts that you need to have in place to deploy a Docker container using Fargate:

  • A Docker image, deployed to a Docker repository, e.g. either Docker Hub, or AWS ECR
  • A VPC with either a public or private subnet (or both)
  • A Security Group to define what traffic is allowed in and out to your running Container
  • A ELB Load Balancer, assuming you’re running more than 1 instance of a container and are not accessing a single instance directly with a public IP
  • An ECS Cluster
  • An ECS Task Definition
  • An ECS Fargate Service Definition to create the running instance of your task

Deploying Docker containers to AWS ECS Fargate

The interesting feature of AWS ECS Fargate is that it’s ‘serverless for containers’. Serverless broadly means you don’t need to be concerned with the provisioning and maintenance of the servers or compute that are running your code. With Fargate, you don’t have to provision compute for your Docker Containers, AWS manages the compute for you.

If you’re working with Docker containers, AWS have multiple runtime options, each with their own pros and cons:

  • running Docker on your own EC2 instances – the roll your own approach, you provision instances and manage everything yourself
  • AWS ECS with EC2 launch type – you still need to provision a pool of available EC2 instances on which AWS will run your containers
  • AWS EKS – managed Kubernetes
  • AWS ECS with Fargate launch type – you don’t need to provision any compute (e.g. EC2), AWS manages the compute for you

I’m taking a look at AWS ECS Fargate to see what it takes to deploy a Docker container.

An ECS cluster needs a VPC in which your container instances will run, with at least 1 public or private subnet. Steps to create a new VPC with subnets is covered here.

Following these steps from the VPC section in ECS tutorials using the AWS Console I created:

  • an Elastic IP to associate with my cluster for public access
  • a new VPC with 1 private subnet and 1 public subnet

I created these with the VPC Wizard using this option:

Apparently your public subnet doesn’t get assigned a public IP by default, so follow these steps in the guide to change this default behavior:

When you select your public subnet, this option is under Actions here:

Select this option:

My public subnet was created in AZ us-west-2a and my private subnet is also in the same AZ. The guide recommends creating 1 additional public and private subnets in a different AZ high for availability.

To create a ECS Fargate cluster you can use the AWS CLI like this:

aws ecs create-cluster --cluster-name your-fargate-cluster-name

This will return some stats about your newly created cluster, like:

"clusterName": "fargate-cluster1",
"status": "ACTIVE",
"registeredContainerInstancesCount": 0,
"runningTasksCount": 0,
"pendingTasksCount": 0,
"activeServicesCount": 0,
"statistics": [],
"tags": [],
"settings": [
{
"name": "containerInsights",
"value": "disabled"
}
],
"capacityProviders": [],
"defaultCapacityProviderStrategy": []

However, I’m not sure at this point how to configure the new cluster to specify the VPC and subnets I just created, so for my first cluster I’m going to use the ECS wizard in the AWS Console first, and then come back to the CLI later.

Using the wizard I selected the Networking Only option with Fargate:

I don’t need to select the ‘Create VPC’ option because I’ve already created one:

Turns out there aren’t any options to associate the VPC at this point, the tasks are associated to your VPC and subnets when you create them next. So using the CLI step earlier would create the cluster exactly the same.

You need to define an ECS task definition that defines the task that will run on the ECS cluster. Following the tutorial here, the example JSON file provided as an example looks like this:

{
"family": "sample-fargate",
"networkMode": "awsvpc",
"containerDefinitions": [
{
"name": "fargate-app",
"image": "httpd:2.4",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
],
"essential": true,
"entryPoint": [
"sh",
"-c"
],
"command": [
"/bin/sh -c \"echo ' Amazon ECS Sample App
body {margin-top: 40px; background-color: #333;}
Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
' > /usr/local/apache2/htdocs/index.html && httpd-foreground\""
]
}
],
"requiresCompatibilities": [
"FARGATE"
],
"cpu": "256",
"memory": "512"
}

Since we’re deploying a Docker container, we need to specify a Docker image to pull some somewhere. This example provides the name of a Docker container to pull from Docker Hub, in this case httpd:2.4. To. deploy your own apps, you configure your own dockerfile for your app, and publish it to a Docker repo like Docker Hub, or AWS ECR.

Register this task definition with:

aws ecs register-task-definition --cli-input-json file://task-def.json

When –cli-input-json reads your config file, it will open is whatever is your default editor in your shell. On my Mac in zsh it appears to open the file in vim with a ‘:’ prompt at the bottom of the screen, and pressing ‘q’ quits the editor and continues registering the Task Def.

You can list registered Task Definitions with:

aws ecs list-task-definitions

By default, your ECS service will only have a private IP, and would typically be exposed publicly via an ELB. You can configure the task to get allocated it’s own public IP by adding this config:

"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "ENABLED",
"securityGroups": [ "sg-12345678" ],
"subnets": [ "subnet-12345678" ]
}
}

This is where we we specify the subnets that were created earlier. I’m going to publicly expose this container, so I’m associating it with the 2 public subnets I created (added to the above config snippet).

I also need a Security Group for the config, so I’ll create that too and allow incoming traffic on port 80.

It’s not obvious from the docs where this NetworkConfiguration section gets specified, but it doesn’t go in the Task Definition json, it gets passed when you create the Service using the Task Definition.

To create a Service, use this cli command:

aws ecs create-service --cluster fargate-cluster --service-name fargate-service --task-definition sample-fargate:1 --desired-count 1 --launch-type "FARGATE" --network-configuration "awsvpcConfiguration={subnets=[subnet-abcd1234],securityGroups=[sg-abcd1234],assignPublicIp=ENABLED}"

Using this command to plug in the subnet ids and Security Group id, from the ECS Console you’ll now see you have service running! If you drill down to the task you can find the assigned public IP. Hit the IP to call the service! Since we’re running an httpd container with a sample web page, we see:

Awesome, up and running!

How online communities develop and evolve

Has anyone written a book or a paper about how online communities evolve over time? Despite best intentions, there always seems to be some undesirable traits or qualities that appear given enough time. For example, StackOverflow has all the ingredients for a great community managed ‘developers helping developers’ Q&A site, and yet among new developers it’s considered a toxic and unwelcoming community. Why is this, and why does this happen?