Charlie and the Chocolatey Factory

Deploying your apps with Chocolatey NuGet

Warner Godfrey

Disclaimer

I’m not a Windows guy.

I’m biased.

Don’t try this on a PaaS.

Practices

What we like

CI/CD Pipeline

1. Build & Test.

2. Package & Publish.

3. Deploy & Release.

Automate all the things!

■ Desktop focus.

■ PowerShell is pretty cool.

■ No standardised package format... yet.

■ Deployment tools.

“To the cloud”

■ Self-managed infrastructure.

■ Scorched earth deployments.

■ Deploy-time vs scale-time.

■ Late-binding of context.

Packaging

What changes together, stays together

Why the fuss?

■ Cohesiveness

■ Explicit dependencies

■ Automation

■ Confidence

Package It, then Ship It!

1. Receive an order.

2. Take assembled product off the shelf.

3. Pack it in a box with some instructions.

4. Slap an address on it.

5. Ship it!

But, doesn’t XYZ tool do that?

⌧ Does it have a CLI?

⌧ Can environment be specified at deploy time?

⌧ Can you declare dependencies?

⌧ Does it work without a server?

⌧ Are deployment scripts managed alongside application

code?

Chocolatey

Just like apt-get…

.nuspec

<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">

<metadata>

<id>invokemsbuild</id>

<title>Invoke-MsBuild PowerShell Module</title>

<version>1.5</version>

...

</metadata>

</package>

.nuspec

<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">

<metadata>...</metadata>

<files>

<file src="*.psm1" target="Modules\Invoke-MSBuild"/>

<file src="Install\**" target="tools"/>

</files>

</package>

chocolateyInstall.ps1

trap {

Write-ChocolateyFailure 'Invoke-MSBuild' $($_.Exception.Message)

Throw $_

}

...

Write-ChocolateySuccess 'Invoke-MSBuild'

chocolateyInstall.ps1

$params = ConvertFrom-StringData ($env:chocolateyPackageParameters -replace ';',

"`n")

$moduleRoot = $params.PSModuleDirectory

if (-not $moduleRoot) {

$moduleRoot = Join-Path $env:USERPROFILE "Documents\WindowsPowerShell\Modules"

}

$moduleTarget = Join-Path $env:chocolateyPackageFolder "Modules"

cmd /c mklink /j "$moduleRoot\Invoke-MSBuild" "$moduleTarget\Invoke-MSBuild"

Write-ChocolateySuccess 'Invoke-MSBuild'

choco install <package_id>

1. .nupkg file is downloaded from source.

2. .nupkg contents are extracted intoC:\ProgramData\chocolatey\lib

3. chocolateyInstall.ps1 script is executed.

4. Any .exe files contained within the package are put on the path via a batch redirect

Not at all like apt-get…

Not as easy as just overlaying some files and restarting a couple of services.

Install scripts get large!

How will it scale?

How do you maintain it?

chocolateyInstall.ps1 (with DSC)Configuration MyApi {

Import-DscResource -Module cNetworking

Import-DscResource -Module cTopShelf

Node 'localhost' {

cUrlReservation ReservePort80 {

Protocol = "http"

Hostname = "*"

Port = "80"

User = "NT AUTHORITY\Network Service"

}

cSelfHostedService Api {

Name = "My.Api"

Executable = $(Join-Path $env:chocolateyPackageFolder "lib\My.Api.exe")

AutoStart = "false"

Start = "false"

}

}

}

chocolateyInstall.ps1 (with DSC)

Configuration MyApi { ... }

MyApi -Force -OutputPath $env:TEMP | Out-Null

Start-DscConfiguration -Wait -Verbose -Path $env:TEMP -ErrorAction Stop

Write-ChocolateySuccess 'My Api'

.nuspec

<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">

<metadata>

...

<dependencies>

<dependency id="seek-dsc-networking"/>

<dependency id="seek-dsc-topshelf"/>

<dependency id="logstash-forwarder"/>

</dependencies>

</metadata>

</package>

Bitter aftertaste

■ Chocolatey install does not play nice with proxies.

■ Package uninstall does not cascade.

■ Packages are installed globally.

■ Uses NuGet dependency resolution rules.

Putting it all together

CI Pipeline

1. Package => .nupkg file

2. Publish => Bundle saved to S3 bucket

Babushka packages

Deploying applications at scale-time often results in unacceptable server boot-time.

It may be necessary to create a machine image that is pre-baked and ready-to-go.

Remember: Keep it environment agnostic!

CD Pipeline

3. Package => AMI

4. Publish => ami.txt

5. Deploy => CloudFormation Stack

6. Release => Happy customers!

Same app, different context

Configuration management tools orchestrate the environment in which your app is deployed.

Application should be able to read configuration from environment variables at start-time.

It should be possible to deploy your package anywhere, even your local development environment.

What lies ahead?

■ One-Get

■ Chocolatey Professional

■ AWS::CloudFormation::Init

Thank You

wgodfrey@dius.com.au@warnergodfreyhttps://github.com/warnergodfrey/https://github.com/SEEK-Jobs/

https://www.slideshare.net/warnergodfrey/pup-charlie-and-the-chocolatey-factory