Azure IoT Edge Module : Error while Build and Push IoT Edge Solution

I followed this tutorial step by step :&nbsp;<a href="https://docs.microsoft.com/en-us/azure/iot-edge/tutorial-c-module" target="_blank">https://docs.microsoft.com/en-us/azure/iot-edge/tutorial-c-module</a>

I followed this tutorial step by step : https://docs.microsoft.com/en-us/azure/iot-edge/tutorial-c-module

But at the step "Build and Push your solution" (https://docs.microsoft.com/en-us/azure/iot-edge/tutorial-c-module#build-and-push-your-solution) I have the following error in the terminal :

standard_init_linux.go:207: exec user process caused "no such file or directory"

I check the 3 points listed on the tutorials ("If you receive an error trying to build and push your module") but I still have the error.

I don't even know what file it is about..

Do someone have an idea of the problem ?

Thanks

EDIT

I add all the terminal output :

Sending build context to Docker daemon    106kB
Step 1/14 : FROM arm32v7/ubuntu:xenial AS base
 ---> 8593318db04f
Step 2/14 : RUN apt-get update && apt-get install -y --no-install-recommends software-properties-common && add-apt-repository -y ppa:aziotsdklinux/ppa-azureiot && apt-get update && apt-get install -y azure-iot-sdk-c-dev && rm -rf /var/lib/apt/lists/*
 ---> Running in 8bed4f396527
standard_init_linux.go:207: exec user process caused "no such file or directory"
The command '/bin/sh -c apt-get update && apt-get install -y --no-install-recommends software-properties-common && add-apt-repository -y ppa:aziotsdklinux/ppa-azureiot && apt-get update && apt-get install -y azure-iot-sdk-c-dev && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 1


WordPress in Docker. Part 1: Dockerization

WordPress in Docker. Part 1: Dockerization

This entry-level guide will tell you why and how to Dockerize your WordPress projects.

This entry-level guide will tell you why and how to Dockerize your WordPress projects.

Get started with Docker Cluster on Azure

Get started with Docker Cluster on Azure

Get started with Docker Cluster on Azure

Prerequisites
  • Completed installation of Docker Desktop Enterprise on Windows or Mac, or the Docker Enterprise Engine on Linux.
  • Sign up for the following items for your Azure account:
    • Service Principal UUID
    • Service Principal App Secret
    • Subscription UUID
    • Tenant UUID

More information can be found on obtaining these with either the Azure CLI or through the Azure Portal.

To securely utilize this Azure credential information, we will create a cluster secrets file which will inject this data into the environment at runtime. For example, create a file named my-azure-creds.sh similar to the following containing your credentials:

export ARM_CLIENT_ID='aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee'
export ARM_CLIENT_SECRET='ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890abcdef='
export ARM_SUBSCRIPTION_ID='ffffffff-gggg-hhhh-iiii-jjjjjjjjjjjj'
export ARM_TENANT_ID='kkkkkkkk-llll-mmmm-nnnn-oooooooooooo'

This file should be treated as sensitive data with file permissions set appropriately. To use this file, we do not source or run this file directly in the shell. Instead, we reference this file via the CLUSTER_SECRETS_FILE variable in our environment before running cluster:

$ export CLUSTER_SECRETS_FILE=~/.my-secrets/my-azure-creds.sh
$ docker cluster create ....

Docker cluster will bindmount this file into its container runtime to inject the credential data as needed.

Create a cluster

When you create a docker cluster in Azure, the cluster created has:

  • 3 UCP Managers
  • 3 Workers
  • 3 DTR Replicas

Create a file called cluster.yml in your directory and paste this in:

variable:
  region: "Azure region to deploy"
  ucp_password: 
    type: prompt

provider:
  azurerm:
    region: ${region}

cluster:
  engine:
    version: ee-stable-19.03
  ucp:
    version: docker/ucp:3.2.0
    username: admin
    password: ${ucp_password}
  dtr:
    version: docker/dtr:2.7.1

resource:
  azurerm_virtual_machine:
    managers:
      quantity: 3
    registry:
      quantity: 3
    workers:
      quantity: 3

  azurerm_lb:
    ucp:
      instances:
      - managers
      ports:
      - "443:443"
      - "6443:6443"

Provide values for the variable section. For instance:

region: "centralus"

The values will be substituted in the cluster definition. This makes it easy to define a reusable cluster definition and then change the variables to create multiple instances of a cluster.

Run docker cluster create --file cluster.yml --name quickstart

$ docker cluster create --file cluster.yml --name quickstart
Please provide a value for ucp_password:
Checking for licenses on Docker Hub
Docker Enterprise Platform 3.0
Planning cluster on azurerm                                                  OK
Creating: [===========>                                              ]  19%  [ ]

After about 5-10 minutes, depending on the number of resources requested, the cluster will be provisioned in the cloud and Docker Enterprise Platform installation will begin:

$ docker cluster create --file cluster.yml --name quickstart
Please provide a value for ucp_password:
Checking for licenses on Docker Hub
Docker Enterprise Platform 3.0
Planning cluster on azurerm                                                   OK
Creating: [==========================================================] 100%   OK
Installing Docker Enterprise Platform                                         OK

After about 15-20 minutes, Docker Enterprise installation will complete:

$ docker cluster create --file cluster.yml --name quickstart
Please provide a value for ucp_password:
Checking for licenses on Docker Hub
Docker Enterprise Platform 3.0
Planning cluster on azurerm                                                   OK
Creating: [==========================================================] 100%   OK
Installing Docker Enterprise Platform                                         OK
Installing Docker Enterprise Engine                                           OK
Installing Docker Universal Control Plane                                     OK
Installing Docker Trusted Registry                                            OK

quickstart
Successfully created context "quickstart"
Connect to quickstart at:

https://ucp-e58dd2a77567-y4pl.centralus.cloudapp.azure.com

e58dd2a77567

After all operations complete succesfully, the cluster id will be the last statement to print. You can login to the URL and begin interacting with the cluster.

View cluster information

To see an inventory of the current clusters you’ve created, run docker cluster ls

$ docker cluster ls
ID             NAME         PROVIDER        ENDPOINT                                                     STATE
e58dd2a77567   quickstart   azurerm         https://ucp-e58dd2a77567-y4pl.centralus.cloudapp.azure.com   running

To see detailed information about an individual cluster, run docker cluster inspect quickstart

$ docker cluster inspect quickstart

name: quickstart
shortid: e58dd2a77567
variable:
  region: centralus
  ucp_password: xxxxxxxxxx
provider:
  azurerm:
    environment: public
    region: centralus
    version: ~> 1.32.1
cluster:
  dtr:
    version: docker/dtr:2.7.1
  engine:
    storage_volume: /dev/disk/azure/scsi1/lun0
    url: https://storebits.docker.com/ee/ubuntu/sub-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    version: ee-stable-19.03
  kubernetes:
    cloud_provider: true
    load_balancer: false
    nfs_storage: false
  subscription:
    id: sub-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    license: /data/license/docker-ee.lic
    trial: "True"
  ucp:
    azure_ip_count: "128"
    pod_cidr: 172.31.0.0/16
    username: admin
    version: docker/ucp:3.2.0
resource:
  azurerm_lb:
    ucp:
      _running:
        dns_name: ucp-e58dd2a77567-y4pl.centralus.cloudapp.azure.com
      path: /data/ssl-certs/
      ports:
      - 443:443
      - 6443:6443
  azurerm_virtual_machine:
    managers:
      data_disk_size: "40"
      enable_public_ips: "true"
      instance_type: Standard_DS3_v2
      os: Ubuntu 18.04
      quantity: 3
      role: manager
    registry:
      data_disk_size: "40"
      enable_public_ips: "true"
      instance_type: Standard_DS3_v2
      os: Ubuntu 18.04
      quantity: 3
      role: dtr
    workers:
      data_disk_size: "40"
      enable_public_ips: "true"
      instance_type: Standard_DS3_v2
      os: Ubuntu 18.04
      quantity: 3
      role: worker

The information displayed by docker cluster inspect can be used as a cluster definition to clone the cluster.

Use context

Docker cluster creates a context on your local machine. To use this context, and interact with the cluster, run docker context use quickstart

$ docker context use quickstart
quickstart
Current context is now "quickstart"

To verify that the client is connected to the cluster, run docker version

$ docker version
Client: Docker Engine - Enterprise
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        f660560
 Built:             Thu Jul 25 20:56:44 2019
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Enterprise 3.0
 Engine:
  Version:          19.03.1
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       f660560
  Built:            Thu Jul 25 20:57:45 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
 Universal Control Plane:
  Version:          3.2.0
  ApiVersion:       1.40
  Arch:             amd64
  BuildTime:        Wed Jul 17 23:27:40 UTC 2019
  GitCommit:        586d782
  GoVersion:        go1.12.7
  MinApiVersion:    1.20
  Os:               linux
 Kubernetes:
  Version:          1.14+
  buildDate:        2019-06-06T16:18:13Z
  compiler:         gc
  gitCommit:        7cfcb52617bf94c36953159ee9a2bf14c7fcc7ba
  gitTreeState:     clean
  gitVersion:       v1.14.3-docker-2
  goVersion:        go1.12.5
  major:            1
  minor:            14+
  platform:         linux/amd64
 Calico:
  Version:          v3.5.7
  cni:              v3.5.7
  kube-controllers: v3.5.7
  node:             v3.5.7

$ docker context use default
default
Current context is now "default"

Scale a cluster

Open cluster.yml. Change the number of workers to 6:

resource:
  azurerm_virtual_machine:
    managers:
      quantity: 3
    registry:
      quantity: 3
    workers:
      quantity: 6

Since the cluster is already created, the next step is to update the cluster’s desired state. Run docker cluster update quickstart --file cluster.yml

$ docker cluster update quickstart --file cluster.yml
Docker Enterprise Platform 3.0
Preparing quickstart                                                       [OK]
Planning cluster on azure                                                  [OK]
Updating: [==================                                            ] 30%

After about 10 minutes the update operation adds the new nodes and joins them to the cluster:

$ docker cluster update quickstart --file examples/docs.yml
Please provide a value for ucp_password
Docker Enterprise Platform 3.0
Preparing quickstart                                                       [OK]
Planning cluster on azure                                                  [OK]
Updating: [==============================================================] 100%
Installing Docker Enterprise Platform Requirements                         [OK]
Installing Docker Enterprise Engine                                        [OK]
Installing Docker Universal Control Plane                                  [OK]
Installing Docker Trusted Registry                                         [OK]

e58dd2a77567

A quick docker cluster inspect e58dd2a77567 will show the worker count increased:

...
    workers:
      data_disk_size: "40"
      enable_public_ips: "true"
      instance_type: Standard_DS3_v2
      os: Ubuntu 18.04
      quantity: 6
      role: worker

Backup a cluster

Before we proceed with more operations on the cluster, let’s take a backup of the running cluster. To create a full backup of the cluster, run docker cluster backup quickstart --file "backup-$(date '+%Y-%m-%d').tar.gz"

Provide a passphrase to encrypt the UCP backup.

$ docker cluster backup quickstart --file "backup-$(date '+%Y-%m-%d').tar.gz"
Passphrase for UCP backup:
Docker Enterprise Platform 3.0
Create archive file.                                                       [OK]

Backup of e58dd2a77567 saved to backup-2019-05-07.tar.gz

Save the backups on external storage for disaster recovery.

To restore a cluster, run docker cluster restore quickstart --file backup-2019-05-07.tar.gz

Provide the passphrase from the backup step to decrypt the UCP backup.

Upgrade a cluster

Open cluster.yml. Change the cluster versions:

cluster:
  dtr:
    version: docker/dtr:2.7.0
  engine:
    version: ee-stable-19.03.01
  ucp:
    version: docker/ucp:3.2.0

Run docker cluster update quickstart --file cluster.yml

$ docker cluster update quickstart --file examples/docs.yml
Please provide a value for ucp_password
Docker Enterprise Platform 3.0
Preparing quickstart                                                       [OK]
Planning cluster on azure                                                  [OK]
Updating: [==============================================================] 100%
Installing Docker Enterprise Platform Requirements                         [OK]
Upgrading Docker Enterprise Engine                                         [OK]
Upgrading Docker Universal Control Plane                                   [OK]
Upgrading Docker Trusted Registry                                          [OK]

e58dd2a77567

Destroy a cluster

When the cluster has reached end-of-life, run docker cluster rm quickstart

$ docker cluster rm quickstart
Removing quickstart
Removing: [==========================================================] 100%   OK

quickstart
e58dd2a77567

How you can do continuous delivery with Vue, Docker, and Azure

How you can do continuous delivery with Vue, Docker, and Azure

How you can do continuous delivery with Vue, Docker, and Azure

A few weeks ago at ng-conf, I announced the launch of vscodecandothat.com — a project I worked on with Sarah Drasner to centralize all of my favorite VS Code tips into a collection of short, silent video clips. It’s like a site full of GIFs, except without the 600 megabyte payload and crashed browser tab.

Sarah designed and built the site using Vue. I put together the video clips with excessive pug references.

Sarah and I both work on the Azure team, so it was a good chance for us to use our own tools here at Microsoft to work with a real application. In this article, I’m going to break down how we do continuous delivery with vscodecandothat.com, and how you can do it yourself using the same tools we use.

Before we talk about the setup, I want to define exactly what I mean by “continuous delivery.”

Continuous something-or-other

The term Continuous Delivery refers to making releases easy, fast, and streamlined. We can argue about the exact definition of the term, but just remember that I am a front-end developer so my eyes may glaze over. I may snore. But go on. I swear I’m listening.

For our purposes, “Continuous Delivery” means that the process of building and deploying the site is completely automated. Here’s how that looks in real life:

  • Developer checks code into Github master branch
  • Build server pulls code from Github
  • Build server runs a build (npm script)
  • Build server creates a Docker container
  • Build server pushes Docker container to registry
  • Burke finds the source of broccoli smell in his office
  • Website pulls in updated container

Got all that? Basically, we’re going to automate everything that you would normally do as a developer so that checking code into Github is all you have to worry about. And lord knows that’s hard enough as it is.

OK, let’s begin at the beginning. The first thing we need to do is look at the application to see how it runs. And how it runs is “In a Docker, y’all.”

Running Vue on Docker

vscodecandothat.com is entirely front-end driven. It’s all HTML, JavaScript, and CSS in your browser. That being the case, all we want to do is serve up the index.html page from the dist folder. We use an nginx web server.

When you are just serving up static assets, the Dockerfile is very simple…

FROM nginx
WORKDIR /app
# Copy in the static build assetsCOPY dist/ /app/
# Copy in the nginx config fileCOPY misc/nginx.conf /etc/nginx/nginx.conf
# All files are in, start the web serverCMD ["nginx"]

Sarah created an nginx configuration file that we just copy in when the container gets built. Because you do not want to be in the business of configuring nginx (OMG you don’t), Sarah has posted her config file to a gist.

I use the [Docker extension for VS Cod](https://marketplace.visualstudio.com/items?itemName=PeterJausovec.vscode-docker&WT.mc_id= vscodecandothat-medium-buhollan)e so that I can see and manage all of my images and containers. I’m not afraid of the terminal, but my brain can only remember so many flags.

Now we need a registry to push the container to. We’re going to configure Azure Container Services (ACR) for that.

You can create an ACR repository from the web portal, but to prove I’m not afraid of the terminal, we’ll do it with the Azure CLI.

First, we need a group for resources. I called mine “vsCodeCanDoThat”.

az group create — name vsCodeCanDoThat — location eastus

Now create the ACR repository. I called mine “hollandcr”.

az acr create --resource-group vsCodeCanDoThat --name hollandcr --sku Basic

Now we can push our image to that by tagging it with the path to the Azure Container Registry.

hollandcr.azurecr.io/vscodecandothat:latest

In the video you can watch me login to the Azure Container Registry from the terminal. This is important because your push will fail if you are not logged in.

OK — now we need a site to host our container. For that we use Azure App Service.

Creating The App Service

First create a Linux service plan. For that, you need your app name and your resource group.

So

az appservice plan create -n appName -g resourceGroupName --is-linux -l "South Central US" --sku S1 --number-of-workers 1

Becomes

az appservice plan create -n vsCodeCanDoThatSP -g vsCodeCanDoThat --is-linux -l "South Central US" --sku S1 --number-of-workers 1

Now create the web app and point it at the container that was pushed to the AKS registry. This takes 4 parameters.

  • Service Plan
  • Resource Group
  • App Name (you haven’t defined this yet)
  • Docker image that you pushed earlier
az webapp create -n vsCodeCanDoThatSP -g vsCodeCanDoThatRG -p vscodecandothat -i hollandcr.azurecr.io/vscodecandothat:latest

And that’s it. You’ll get back a URL, and you should be able to open it and see your site running.

Now what we want to do is automate everything that we just did. We never ever want to have to go through any of these steps again.

The first thing we will do is to set up our site for “Continuous Deployment” from our container registry.

If you are using the App Service extension for VS Code, all of your Azure sites will show up right in the editor. You can just right-click and say “Open in Portal.”

Select the “Docker Container” menu option…

On this page you will see the container you configured from the terminal. There is an option at the bottom to turn on “Continuous Deployment.”

When you toggle this on and click “save,” a webhook will get created in your Azure Container Registry for this specific container. Now, anytime the image with tag “latest” is updated, the webhook will fire and notify App Service which automatically pulls in your image.

So we’ve automated some of this already. Once we push the image, it will be deployed. There is nothing we have to do besides push it. But we don’t want to push it. We want someone else to that.

And who will do it? The robots, that’s who. Or whom? OR WHOMST. Fortunately I’m not in high school English anymore. I failed it once and that was enough.

Setting up a build server

This is the point at which I tell you that we are going to use Visual Studio Team Services (VSTS). Then you say, “Visual Studio? I’m not using .NET”. And I say, “I know, it’s confusing.”

We need a system specifically designed to automate builds and deployment. This is exactly what VSTS is/does. Also, it’s free for 5 users or less (in a project space) and “free” is the only word in my love language. The only word besides “beer.”

Create a VSTS account if you don’t have one. Once you do, you land on the dashboard screen.

From here, you want to create a new team project.

Give your project a name and a description that nobody will find helpful. Leave the version control at Git.

The next screen gives you a Git URL to check your code into. But we already have Github, so just ignore that and select the “or build code from an external repository” option.

Authorize VSTS to Github and select the repo…

The next screen is offering to help you start with a template. In this case we are going to roll from an empty process. Because we are hard core like that.

Now we are going to start adding steps for VSTS to perform to do the build and deployment. The pull from source control is already happening, so the first thing we need to do is to run npm install on our code. To do that, add a task to “phase 1”. There is only 1 phase in our build / deployment.

Search for “npm” and add the npm task.

By default, you get the npm install task, which is exactly what we want. You don’t need to add any options to this task.

Next, we’ll be running the npm run build command, which will build a production instance of our Vue app with all of its Webpacking magic. For that, add another npm task. This time, change the name to “npm run build.” Set the “command” to “custom” and the “command and arguments” to “run build.”

Great! We’ve got the build, now we’re ready to Dockerize it. Add a new task and find the “Docker” one.

This is a big screen, so here’s the image and then we’ll walkthrough the highlights.

  • You are selecting the “Azure Container Registry”
  • Specify your Azure subscription
  • Specify your registry name (which we created earlier)
  • Set the “Image Name” to $(Build.Repository.Name)
  • Make sure you check the “Include Latest Tag”

Lastly, we want to push the image. Add another Docker task. This time, set the “Action” to “Push an image”. Set the “Image Name” to $(Build.Repository.Name) — just like before.

DO NOT SELECT THE “PUSH IMAGES” ACTION. If you do, your build will fail and you will blame god and all humanity before you figure out that you selected the wrong action. Don’t ask me how I know that.

And that’s it for defining the Build definition. You can now click “save and queue” at the top. Make sure that you select a “Hosted Linux Preview” agent. The Docker tasks needs the Linux agent.

Now sit back and wait for a build to kick off. If you’ve done everything right, you have now setup a completely automated build and deployment system for a Vue app that utilizes Docker and Azure. That’s the most buzzwords I’ve ever squeezed into one sentence.

Deploy and be happy

This seems like a lot to setup, but once you have it just like you want it, all you have to do is check in code to your Github repo and all of this manual deployment 💩 happens automatically. Your customers will love you. Your developers will love you. Heck — even YOU might love you.

I hope you find this helpful. I’m off to update my résumé with all of these buzzwords.

30s ad

Vue.js 2 Academy: Learn Vue Step by Step

Vue.js 2 Essentials: Build Your First Vue App

Nuxt: Supercharged Vue JS

Vue.js Fast Crash Course

Vue JS 2: From Beginner to Professional (includes Vuex)