Sam Merrell Tinkerer. Parent. ADHD. Developer.

Posts

Azure Web App for Containers Using Terraform

Recently at work I have been tasked with helping our organization transition from our traditional on-premises infrastructure to Azure. To do that, I’ve been learning how to automate our infrastructure by using HashiCorp’s Terraform. Terraform was introduced to me by a few members of our infrastructure team and I’ve found it quite fun to work with.

As I’ve been working on what direction we’d like to head, I’ve focused on new apps using Platform as a Service, specifically Azure Web Apps. A few months back I noticed that Web Apps had a new option for using Docker containers, so about a week ago I decided to see if I could create an Azure Web App for Containers using Terraform.

It turns out, this is already possible but it took some fiddling to figure out what I needed to set up in Terraform. I assume this isn’t very well documented yet because Azure Web App for Containers only recently went GA. So to make sure I remember how to do this, and if anyone else could use this, I’m writing this down here.

Creating the Container Registry

You first have to have the container registry created before you create the App Service. Creating the container registry is no different than what is described in the azurem provider documentation. The main thing to note is that from the tests I was running, I needed to have the container registry created well before I created the App Service Plan and App Service. Otherwise it seemed that the Azure Web App didn’t recognize the container registry.

The example documentation does use the Classic SKU, I went ahead and changed that to use Basic. If you do that, you do not need to create a separate Storage Account. I chose to do this because the Azure Portal suggested upgrading from Classic to Basic.

Creating the App Service Plan

The App Service plan is close to the same as the documentation. The main thing to make sure you set is the fact that it is a Linux plan.

resource "azurerm_app_service_plan" "containertest" {
  name                = "container-test-plan"
  location            = "eastus2"
  resource_group_name = "test-resource-group"
  kind                = "Linux"

  properties {
    reserved = true
  }
}

I also put this as a reserved instance, but I’m not 100% sure that is needed.

Creating the App Service

This was the trickiest part. Not only do you have to set some site_config properties. You also have to set a few app settings as well.

Here is what the Terraform config looks like to get this set up right.

resource "azurerm_app_service" "containertest" {
  name                = "someuniquename01"
  location            = "eastus2"
  resource_group_name = "test-resource-group"
  app_service_plan_id = "${azurerm_app_service_plan.containertest.id}"

  site_config {
    always_on        = true
    linux_fx_version = "DOCKER|${data.azurerm_container_registry.containertest.login_server}/testdocker-alpine:v1"
  }

  app_settings {
    "WEBSITES_ENABLE_APP_SERVICE_STORAGE" = "false"
    "DOCKER_REGISTRY_SERVER_URL"          = "https://${data.azurerm_container_registry.containertest.login_server}"
    "DOCKER_REGISTRY_SERVER_USERNAME"     = "${data.azurerm_container_registry.containertest.admin_username}"
    "DOCKER_REGISTRY_SERVER_PASSWORD"     = "${data.azurerm_container_registry.containertest.admin_password}"
  }
}

The big part here to notice is the linux_fx_version under site_config. The documentation in the azurerm provider isn’t super clear how this works. The example uses DOCKER|(golang:latest). What it doesn’t show or explain is that string uses Dockerhub. If you want to use a different registry the format looks like this DOCKER|<registryurl>/<container>:<tag>.

Under app_settings I had to create an app service from the Azure portal and poke around the settings to reverse engineer what I needed in my terraform config. Not only do you need the linux_fx_version property that has the registry URL, you also have to set that as an app setting. Once that happens, you need a username and password to access the registry. Fortunately Terraform exposes all of this information so you can reference the properties as data.

This should get you up and running with a Web App for Container. This took a few hours of my weekend to get running. Hopefully this can help others get up and running more quickly. I’ll eventually come back to this and try getting this down to the smallest set possible as there are a few items I’m not 100% sure I actually need. If I get a smaller setup, I’ll update the post with that information.


Getting to Know Swift

For the last several years I’ve primarily been a backend developer using C# and occasionally doing work on the frontend with JavaScript. I’ve dabbled in learning Rust as well but I wanted to try my hand at writing native iOS and macOS applications for a change.

After doing some research on where to begin, I started reading the book App Development with Swift by Apple. This book has been a great guide for learning Swift through developing iOS applications. The book is broken up into distinct sections where they teach you features of Swift and then show you how to use them when writing many iOS applications. Apple wrote this book to be used in classrooms but I’ve been following along on my own time during the evenings.

The book has you do bunches of small projects in XCode which has been extremely helpful in learning XCode. Since I’m a Vim person I’ve found it extremely difficult – but worth it – to learn the native keyboard shortcuts on the Mac as well as in XCode itself. Having to do so many different projects has already gotten me much more comfortable using XCode and Interface builder.

What about Xamarin

Xamarin looks like a great option for C# developers who want to keep using C# or share code with Android and iOS applications. This is not the problem I am trying to solve. I enjoy learning new things and since I use C# daily at work, I wanted to give native app development a chance. The concepts I learn writing iOS and macOS applications in Swift will help me if my company ever needs a native app written. Even though they’d likely use Xamarin (we are a C# heavy office after all) I will learn a great deal about the underlying platform. That knowledge will be useful whether or not I am writing code in Swift or C#.

What do I like about Swift right now

So far Swift has been a lot of fun to learn. I’m getting to try out a new language as well as two different native paradigms of iOS and macOS development. I found Objective-C’s syntax to be hard to follow and I was always a bit afraid of managing my own memory. So far this is what I have liked about Swift as well as what I’ve found confusing.

Optionals

Handling optionals in Swift is pretty easy. this syntax is pretty similar to what I learned from Rust. It is something that I’d love to see C# take a cue from.

let someOptional: OptionalType?
if let someOptional = someOptional {
    // use the now unwrapped someOptional
} else {
    // some optional was nil
}

Guard statements

Guard statements have been awesome, they combine a lot of what I like about how swift handles optionals and lets me invert the check so my code doesn’t get to be an arrowhead. I also like that you can do additional checks and have your function return.

func someFunction(some nullableParameter: SomeParameter) {
    guard let parameter = nullableParameter else { return }

    // use parameter here
}

One thing I’ll eventually want to figure out with guard statements, is what the general suggestions for formatting a guard statement are. I’m writing them like this for now:

guard let symbol = aDecoder.decodeObject(forKey: PropertyKey.symbol) as? String,
      let name = aDecoder.decodeObject(forKey: PropertyKey.name) as? String,
      let detailDescription = aDecoder.decodeObject(forKey: PropertyKey.detailDescription) as? String,
      let usage = aDecoder.decodeObject(forKey: PropertyKey.usage) as? String
else { return nil }

Generics

I haven’t gotten too far into using Generics in Swift yet but they feel pretty similar to what I’ve gotten used to in C# and Rust.

What confuses me about Swift so far

I’ve run into a few things in Swift that I’ve found confusing. Either from suggestions on how you should organize your code using Extensions or more historical aspects of iOS and macOS.

Extensions

I’m used to C# where extension methods currently are static methods that operate on a type. In Swift, that doesn’t seem to be the case, you can extend most classes it looks like including adding interface implementations or mutating functions. It also seems like some style guides prefer you to break up a class or struct by having interface implementations go into extensions. I’ll have to dig into extensions a little more to understand them.

iOS and macOS differences

This isn’t really specifically about Swift but more the platforms I’m using swift on. Either way, it is confusing that it looks like iOS and macOS have similar APIs in Swift but there seems to be a version of the same objects across the platforms. On macOS everything is NSSomething where in iOS it looks like there is always a UISomething. It hasn’t been extremely confusing but I have had to do some translating when trying to write code for the Mac when the examples I’ve been looking at have been for iOS.

What about Objective-C

As I’ve tried to learn about writing apps for macOS, I’ve noticed that a large number of examples are written in Objective-C. This isn’t a bad thing but I avoided learning iOS and macOS development for a long time because of Objective-C. So what about Objective-C now? Ultimately, it isn’t that bad and I’ve been able to understand most API examples even if they are written in Objective-C.

The release of Swift 4 has made large strides in the API surface area it also seems. Many of the APIs had a decidedly C or Objective-C feel to them but there seems to be a big effort by Apple to make more APIs feel natural in Swift.

Ultimately, I’ll teach myself at least some Objective-C. If I want to do anything significant in Swift I likely am going to have to deal with some Objective-C code for a long time to come. For now though, I’ll try to stick to just Swift.

Goals learning Swift

I decided to learn Swift because I wanted to learn a new programming paradigm I’ve never used before. At my job right now, I do almost exclusively backed web development using C#. I don’t get much time to work on UIs or native app development. To that end, I thought I’d give macOS development a try and have been working on a simple Pomodoro timer for the Mac.

I want to eventually have enough skills with Swift (and probably a little Objective-C) that I could be a passable native iOS or macOS developer. I don’t know what the job opportunities look like there but it doesn’t really matter that much. Perhaps I’ll try to release an app or two on the App Store, either way, I’ll have learned a new skill that I would enjoy.


Discovering Podcasts

I’ve never paid much attention to podcasts. Up until a few months ago I was commuting to work by train and used that time to either read books, or play games. All of that has been great and I’ve enjoyed the time I have had to read, relax, or learn something new. Recently, I’ve had to begin commuting to work which completely threw the routine I had developed.

Since I can’t really read or play games commuting, I had to find another alternative. I remembered my iPhone has a Podcasting app built in so I decided to dive in. After a bit of Googling, I came across Developer on Fire and decided to give it a spin. The very first episode I listened to was with Woody Zuill. By the time I had pulled into the parking lot, I had an idea I had learned from the podcast I wanted to share with my team.

That experience hooked me on how useful a Podcast can be. I spend so much time commuting each day and I don’t want to be wasting that time only driving. Since then I’ve been searching for a range of podcasts to listen to. Here are the podcasts I’m currently listening to.

  1. .NET Rocks!
  2. Another Round
  3. CodeNewbie
  4. Developer On Fire
  5. Developer Tea
  6. Edit Your Life
  7. Hanselminutes
  8. New Rustacean
  9. The Psychology Podcast
  10. This Developers Life

Not Just Development Podcasts

At first, I was just listening to Developer on Fire and Developer Tea but it has been great to expand that list with a few podcasts on other topics I’m interested in. For example, The Psychology Podcast with Dr. Scott Barry Kaufman is a great podcast that focuses on a range of topics in psychology. Some great episodes have been on understanding and supporting people with ADHD and learning about the concept of Grit.

Edit Your Life is also a great podcast about simplifying and decluttering your life. Hosts Asha Dornfest and Christine Koh have episodes on varying topics from parenting, personal finances and general relationship tips. I’ve found their episodes to be fun and very informative.

Really branching out and listening to more than just podcasts has been a really great and informative time. I’ll wrap this up now, but if you have any podcasts you enjoy, please let me know on Twitter!


Keeping up with JavaScript

I like JavaScript, I really do, but I just haven’t been able to keep up with the insane change that is going on in that world. Over the last several months at work I’ve been building out a project that is mostly back end work. When I have been able to do any sort of front end work, it has been in a desktop Windows application using WPF.

While working on this application I started to realize I don’t have my finger on the pulse of the JavaScript world like I once had several years ago. Things have changed since Node and NPM made it incredibly easy to write JavaScript on both the server side and client side and to distribute that code. I’ll be honest, I got a little scared when I realized I just don’t know what all the latest and greatest changes in the world of JavaScript. What’s going to happen if people find out I don’t know what the next great Flux framework is? Or that I don’t really know what all is going on with the next version of JavaScript? Is it called ES7 or is it ES2016?

All of that got me pretty worried until a co-worker of mine dropped this statement:

It doesn’t matter if you step away from JavaScript for a while. As soon as you pick it back up, the next big thing will have come out just yesterday anyway.

I still think it is silly how much things are changing and how much churn is happening, but I can take comfort in one thing. Everyone else will basically be working on the next new awesome JavaScript thing for as long as I have.