зеркало из https://github.com/Azure/acs-engine.git
Build Linux, Mac, and Windows binaries (#1077)
* chore(Makefile): improve bootstrap command * ref(Makefile): refactor `make build`, use go install * chore(release): support building windows, linux, macos binaries * ref(Makefile): change name order of bins (project-ver-platform-arch) * fix(ci): fix path of acs-engine binary * fix(Makefile): fix wrong argument in go install
This commit is contained in:
Родитель
bb1840b049
Коммит
05871f14ea
|
@ -8,6 +8,8 @@ test/user.env
|
|||
user.env
|
||||
test/acs-engine-test/acs-engine-test
|
||||
.editorconfig
|
||||
_dist/
|
||||
bin/
|
||||
|
||||
test/acs-engine-test/acs-engine-test.exe
|
||||
pkg/operations/junit.xml
|
||||
|
|
82
Makefile
82
Makefile
|
@ -1,9 +1,19 @@
|
|||
TARGETS = darwin/amd64 linux/amd64 windows/amd64
|
||||
DIST_DIRS = find * -type d -exec
|
||||
|
||||
.NOTPARALLEL:
|
||||
|
||||
.PHONY: prereqs build test test_fmt validate-generated fmt lint ci devenv
|
||||
.PHONY: bootstrap build test test_fmt validate-generated fmt lint ci devenv
|
||||
|
||||
VERSION=`git describe --always --long --dirty`
|
||||
BUILD=`date +%FT%T%z`
|
||||
# go option
|
||||
GO ?= go
|
||||
PKG := $(shell glide novendor)
|
||||
TAGS :=
|
||||
LDFLAGS :=
|
||||
GOFLAGS :=
|
||||
BINDIR := $(CURDIR)/bin
|
||||
BINARIES := acs-engine
|
||||
VERSION := $(shell git rev-parse HEAD)
|
||||
|
||||
# this isn't particularly pleasant, but it works with the least amount
|
||||
# of requirements around $GOPATH. The extra sed is needed because `gofmt`
|
||||
|
@ -13,15 +23,40 @@ GOFILES=`go list ./... | grep -v "github.com/Azure/acs-engine/vendor" | sed 's|g
|
|||
|
||||
all: build
|
||||
|
||||
prereqs:
|
||||
go get github.com/Masterminds/glide
|
||||
go get github.com/jteeuwen/go-bindata/...
|
||||
glide install
|
||||
|
||||
build:
|
||||
.PHONE: generate
|
||||
generate:
|
||||
go generate -v $(GOFILES)
|
||||
go build -v -ldflags="-X github.com/Azure/acs-engine/cmd.BuildSHA=${VERSION} -X github.com/Azure/acs-engine/cmd.BuildTime=${BUILD}"
|
||||
cd test/acs-engine-test; go build -v
|
||||
|
||||
.PHONY: build
|
||||
build: generate
|
||||
GOBIN=$(BINDIR) $(GO) install $(GOFLAGS) -ldflags '$(LDFLAGS)'
|
||||
cd test/acs-engine-test; go build
|
||||
|
||||
# usage: make clean build-cross dist VERSION=v0.4.0
|
||||
.PHONY: build-cross
|
||||
build-cross: LDFLAGS += -extldflags "-static"
|
||||
build-cross:
|
||||
CGO_ENABLED=0 gox -output="_dist/acs-engine-${VERSION}-{{.OS}}-{{.Arch}}/{{.Dir}}" -osarch='$(TARGETS)' $(GOFLAGS) -tags '$(TAGS)' -ldflags '$(LDFLAGS)'
|
||||
|
||||
.PHONY: dist
|
||||
dist:
|
||||
( \
|
||||
cd _dist && \
|
||||
$(DIST_DIRS) cp ../LICENSE {} \; && \
|
||||
$(DIST_DIRS) cp ../README.md {} \; && \
|
||||
$(DIST_DIRS) tar -zcf {}.tar.gz {} \; && \
|
||||
$(DIST_DIRS) zip -r {}.zip {} \; \
|
||||
)
|
||||
|
||||
.PHONY: checksum
|
||||
checksum:
|
||||
for f in _dist/*.{gz,zip} ; do \
|
||||
shasum -a 256 "$${f}" | awk '{print $$1}' > "$${f}.sha256" ; \
|
||||
done
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
@rm -rf $(BINDIR) ./_dist
|
||||
|
||||
test: test_fmt
|
||||
go test -v $(GOFILES)
|
||||
|
@ -30,7 +65,28 @@ test: test_fmt
|
|||
test-style:
|
||||
@scripts/validate-go.sh
|
||||
|
||||
ci: prereqs build test lint
|
||||
HAS_GLIDE := $(shell command -v glide;)
|
||||
HAS_GOX := $(shell command -v gox;)
|
||||
HAS_GIT := $(shell command -v git;)
|
||||
HAS_GOBINDATA := $(shell command -v go-bindata;)
|
||||
|
||||
.PHONY: bootstrap
|
||||
bootstrap:
|
||||
ifndef HAS_GLIDE
|
||||
go get -u github.com/Masterminds/glide
|
||||
endif
|
||||
ifndef HAS_GOX
|
||||
go get -u github.com/mitchellh/gox
|
||||
endif
|
||||
ifndef HAS_GOBINDATA
|
||||
go get github.com/jteeuwen/go-bindata/...
|
||||
endif
|
||||
ifndef HAS_GIT
|
||||
$(error You must install Git)
|
||||
endif
|
||||
glide install
|
||||
|
||||
ci: bootstrap build test lint
|
||||
./scripts/coverage.sh --coveralls
|
||||
|
||||
.PHONY: coverage
|
||||
|
@ -39,3 +95,5 @@ coverage:
|
|||
|
||||
devenv:
|
||||
./scripts/devenv.sh
|
||||
|
||||
include versioning.mk
|
||||
|
|
|
@ -1,156 +1,156 @@
|
|||
# Microsoft Azure Container Service Engine
|
||||
|
||||
The Azure Container Service Engine (`acs-engine`) generates ARM (Azure Resource Manager) templates for Docker enabled clusters on Microsoft Azure with your choice of DCOS, Kubernetes, or Swarm orchestrators. The input to the tool is a cluster definition. The cluster definition is very similar to (in many cases the same as) the ARM template syntax used to deploy a Microsoft Azure Container Service cluster.
|
||||
|
||||
# Development in Docker
|
||||
|
||||
The easiest way to get started developing on `acs-engine` is to use Docker. If you already have Docker or "Docker for {Windows,Mac}" then you can get started without needing to install anything extra.
|
||||
|
||||
* Windows (PowerShell): `.\scripts\devenv.ps1`
|
||||
* Linux/OSX (bash): `./scripts/devenv.sh`
|
||||
|
||||
This setup mounts the `acs-engine` source directory as a volume into the Docker container.
|
||||
This means that you can edit your source code normally in your favorite editor on your
|
||||
machine, while still being able to compile and test inside of the Docker container (the
|
||||
same environment used in our Continuous Integration system).
|
||||
|
||||
When the execution of `devenv.{ps1,sh}` completes, you should find the console logged into the container.
|
||||
|
||||
Now we need to do a one-time call to setup the prerequisites.
|
||||
|
||||
```
|
||||
make prereqs
|
||||
```
|
||||
|
||||
As a final step, in order to get the `acs-engine` tool ready, you should build the sources with:
|
||||
|
||||
```
|
||||
make build
|
||||
```
|
||||
|
||||
When the build process completes, verify that `acs-engine` is available, invoking the command without parameters.
|
||||
You should see something like this:
|
||||
|
||||
```
|
||||
# ./acs-engine
|
||||
ACS-Engine deploys and manages Kubernetes, Swarm Mode, and DC/OS clusters in Azure
|
||||
|
||||
Usage:
|
||||
acs-engine [command]
|
||||
|
||||
Available Commands:
|
||||
generate Generate an Azure Resource Manager template
|
||||
help Help about any command
|
||||
version Print the version of ACS-Engine
|
||||
|
||||
Flags:
|
||||
--debug enable verbose debug logs
|
||||
-h, --help help for acs-engine
|
||||
|
||||
Use "acs-engine [command] --help" for more information about a command.
|
||||
```
|
||||
|
||||
[Here's a quick demo video showing the dev/build/test cycle with this setup.](https://www.youtube.com/watch?v=lc6UZmqxQMs)
|
||||
|
||||
# Downloading and Building ACS Engine Locally
|
||||
|
||||
ACS Engine can also be built and run natively on Windows, OS X, and Linux. Instructions below:
|
||||
|
||||
## Windows
|
||||
|
||||
Requirements:
|
||||
- Git for Windows. Download and install [here](https://git-scm.com/download/win)
|
||||
- Go for Windows. Download and install [here](https://golang.org/dl/), accept all defaults.
|
||||
- Powershell
|
||||
|
||||
Build Steps:
|
||||
|
||||
1. Setup your go workspace. This example assumes you are using `c:\gopath` as your workspace:
|
||||
1. Windows key-R to open the run prompt
|
||||
2. `rundll32 sysdm.cpl,EditEnvironmentVariables` to open the system variables
|
||||
3. add `c:\go\bin` to your PATH variables
|
||||
4. click "new" and add new environment variable GOPATH and set to `c:\gopath`
|
||||
|
||||
Build acs-engine:
|
||||
1. Windows key-R to open the run prompt
|
||||
2. `cmd` to open command prompt
|
||||
3. mkdir %GOPATH%
|
||||
4. cd %GOPATH%
|
||||
5. type `go get github.com/Azure/acs-engine` to get the acs-engine Github project
|
||||
6. type `go get all` to get the supporting components
|
||||
7. `cd %GOPATH%\src\github.com\Azure\acs-engine`
|
||||
8. `go build` to build the project
|
||||
3. `acs-engine` to see the command line parameters
|
||||
|
||||
## OS X
|
||||
|
||||
Requirements:
|
||||
- Go for OS X. Download and install [here](https://golang.org/dl/)
|
||||
|
||||
Build Steps:
|
||||
|
||||
1. Open a command prompt to setup your gopath:
|
||||
2. `mkdir $HOME/gopath`
|
||||
3. edit `$HOME/.bash_profile` and add the following lines to setup your go path
|
||||
```
|
||||
export PATH=$PATH:/usr/local/go/bin
|
||||
export GOPATH=$HOME/gopath
|
||||
```
|
||||
4. `source $HOME/.bash_profile`
|
||||
Build acs-engine:
|
||||
1. type `go get github.com/Azure/acs-engine` to get the acs-engine Github project
|
||||
2. type `go get all` to get the supporting components
|
||||
3. `cd $GOPATH/src/github.com/Azure/acs-engine`
|
||||
4. `go build` to build the project
|
||||
5. `./acs-engine` to see the command line parameters
|
||||
|
||||
## Linux
|
||||
|
||||
Requirements:
|
||||
- Go for Linux
|
||||
- Download the appropriate archive for your system [here](https://golang.org/dl/)
|
||||
- sudo tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz (replace with your downloaded archive)
|
||||
- `git`
|
||||
|
||||
Build Steps:
|
||||
|
||||
1. Setup Go path:
|
||||
2. `mkdir $HOME/gopath`
|
||||
3. edit `$HOME/.profile` and add the following lines to setup your go path
|
||||
```
|
||||
export PATH=$PATH:/usr/local/go/bin
|
||||
export GOPATH=$HOME/gopath
|
||||
```
|
||||
4. `source $HOME/.profile`
|
||||
|
||||
Build acs-engine:
|
||||
1. type `go get github.com/Azure/acs-engine` to get the acs-engine Github project
|
||||
2. type `go get all` to get the supporting components
|
||||
3. `cd $GOPATH/src/github.com/Azure/acs-engine`
|
||||
4. `go build` to build the project
|
||||
5. `./acs-engine` to see the command line parameters
|
||||
|
||||
|
||||
# Template Generation
|
||||
|
||||
The `acs-engine` takes a json [cluster definition file](clusterdefinition.md) as a parameter and generates 3 or more of the following files:
|
||||
|
||||
1. **apimodel.json** - this is the cluster configuration file used for generation
|
||||
2. **azuredeploy.json** - this is the main ARM (Azure Resource Model) template used to deploy a full Docker enabled cluster
|
||||
3. **azuredeploy.parameters.json** - this is the parameters file used along with azurdeploy.json during deployment and contains configurable parameters
|
||||
4. **certificate and access config files** - some orchestrators like Kubernetes require certificate generation, and these generated files and access files like the kube config files are stored along side the model and ARM template files.
|
||||
|
||||
As a rule of thumb you should always work with the `apimodel.json` when modifying an existing running deployment. This ensures that all the same settings and certificates are correctly preserved. For example, if you want to add a second agent pool, you would edit `apimodel.json` and then run `acs-engine` against that file to generate the new ARM templates. Then during deployment all existing deployments remain untouched, and only the new agent pools resources are created.
|
||||
|
||||
# Generating a template
|
||||
|
||||
Here is an example of how to generate a new deployment. This example assumes you are using [examples/kubernetes.json](../examples/kubernetes.json).
|
||||
|
||||
1. Before starting ensure you have generated a valid [SSH Public/Private key pair](ssh.md#ssh-key-generation).
|
||||
2. edit [examples/kubernetes.json](../examples/kubernetes.json) and fill in the blanks.
|
||||
3. run `./acs-engine generate examples/kubernetes.json` to generate the templates in the _output/Kubernetes-UNIQUEID directory. The UNIQUEID is a hash of your master's FQDN prefix.
|
||||
4. now you can use the `azuredeploy.json` and `azuredeploy.parameters.json` for deployment as described in [deployment usage](../README.md#deployment-usage).
|
||||
|
||||
# Deploying templates
|
||||
|
||||
For deployment see [deployment usage](../README.md#deployment-usage).
|
||||
# Microsoft Azure Container Service Engine
|
||||
|
||||
The Azure Container Service Engine (`acs-engine`) generates ARM (Azure Resource Manager) templates for Docker enabled clusters on Microsoft Azure with your choice of DCOS, Kubernetes, or Swarm orchestrators. The input to the tool is a cluster definition. The cluster definition is very similar to (in many cases the same as) the ARM template syntax used to deploy a Microsoft Azure Container Service cluster.
|
||||
|
||||
# Development in Docker
|
||||
|
||||
The easiest way to get started developing on `acs-engine` is to use Docker. If you already have Docker or "Docker for {Windows,Mac}" then you can get started without needing to install anything extra.
|
||||
|
||||
* Windows (PowerShell): `.\scripts\devenv.ps1`
|
||||
* Linux/OSX (bash): `./scripts/devenv.sh`
|
||||
|
||||
This setup mounts the `acs-engine` source directory as a volume into the Docker container.
|
||||
This means that you can edit your source code normally in your favorite editor on your
|
||||
machine, while still being able to compile and test inside of the Docker container (the
|
||||
same environment used in our Continuous Integration system).
|
||||
|
||||
When the execution of `devenv.{ps1,sh}` completes, you should find the console logged into the container.
|
||||
|
||||
Now we need to do a one-time call to setup the prerequisites.
|
||||
|
||||
```
|
||||
make bootstrap
|
||||
```
|
||||
|
||||
As a final step, in order to get the `acs-engine` tool ready, you should build the sources with:
|
||||
|
||||
```
|
||||
make build
|
||||
```
|
||||
|
||||
When the build process completes, verify that `acs-engine` is available, invoking the command without parameters.
|
||||
You should see something like this:
|
||||
|
||||
```
|
||||
# ./acs-engine
|
||||
ACS-Engine deploys and manages Kubernetes, Swarm Mode, and DC/OS clusters in Azure
|
||||
|
||||
Usage:
|
||||
acs-engine [command]
|
||||
|
||||
Available Commands:
|
||||
generate Generate an Azure Resource Manager template
|
||||
help Help about any command
|
||||
version Print the version of ACS-Engine
|
||||
|
||||
Flags:
|
||||
--debug enable verbose debug logs
|
||||
-h, --help help for acs-engine
|
||||
|
||||
Use "acs-engine [command] --help" for more information about a command.
|
||||
```
|
||||
|
||||
[Here's a quick demo video showing the dev/build/test cycle with this setup.](https://www.youtube.com/watch?v=lc6UZmqxQMs)
|
||||
|
||||
# Downloading and Building ACS Engine Locally
|
||||
|
||||
ACS Engine can also be built and run natively on Windows, OS X, and Linux. Instructions below:
|
||||
|
||||
## Windows
|
||||
|
||||
Requirements:
|
||||
- Git for Windows. Download and install [here](https://git-scm.com/download/win)
|
||||
- Go for Windows. Download and install [here](https://golang.org/dl/), accept all defaults.
|
||||
- Powershell
|
||||
|
||||
Build Steps:
|
||||
|
||||
1. Setup your go workspace. This example assumes you are using `c:\gopath` as your workspace:
|
||||
1. Windows key-R to open the run prompt
|
||||
2. `rundll32 sysdm.cpl,EditEnvironmentVariables` to open the system variables
|
||||
3. add `c:\go\bin` to your PATH variables
|
||||
4. click "new" and add new environment variable GOPATH and set to `c:\gopath`
|
||||
|
||||
Build acs-engine:
|
||||
1. Windows key-R to open the run prompt
|
||||
2. `cmd` to open command prompt
|
||||
3. mkdir %GOPATH%
|
||||
4. cd %GOPATH%
|
||||
5. type `go get github.com/Azure/acs-engine` to get the acs-engine Github project
|
||||
6. type `go get all` to get the supporting components
|
||||
7. `cd %GOPATH%\src\github.com\Azure\acs-engine`
|
||||
8. `go build` to build the project
|
||||
3. `acs-engine` to see the command line parameters
|
||||
|
||||
## OS X
|
||||
|
||||
Requirements:
|
||||
- Go for OS X. Download and install [here](https://golang.org/dl/)
|
||||
|
||||
Build Steps:
|
||||
|
||||
1. Open a command prompt to setup your gopath:
|
||||
2. `mkdir $HOME/gopath`
|
||||
3. edit `$HOME/.bash_profile` and add the following lines to setup your go path
|
||||
```
|
||||
export PATH=$PATH:/usr/local/go/bin
|
||||
export GOPATH=$HOME/gopath
|
||||
```
|
||||
4. `source $HOME/.bash_profile`
|
||||
Build acs-engine:
|
||||
1. type `go get github.com/Azure/acs-engine` to get the acs-engine Github project
|
||||
2. type `go get all` to get the supporting components
|
||||
3. `cd $GOPATH/src/github.com/Azure/acs-engine`
|
||||
4. `go build` to build the project
|
||||
5. `./acs-engine` to see the command line parameters
|
||||
|
||||
## Linux
|
||||
|
||||
Requirements:
|
||||
- Go for Linux
|
||||
- Download the appropriate archive for your system [here](https://golang.org/dl/)
|
||||
- sudo tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz (replace with your downloaded archive)
|
||||
- `git`
|
||||
|
||||
Build Steps:
|
||||
|
||||
1. Setup Go path:
|
||||
2. `mkdir $HOME/gopath`
|
||||
3. edit `$HOME/.profile` and add the following lines to setup your go path
|
||||
```
|
||||
export PATH=$PATH:/usr/local/go/bin
|
||||
export GOPATH=$HOME/gopath
|
||||
```
|
||||
4. `source $HOME/.profile`
|
||||
|
||||
Build acs-engine:
|
||||
1. type `go get github.com/Azure/acs-engine` to get the acs-engine Github project
|
||||
2. type `go get all` to get the supporting components
|
||||
3. `cd $GOPATH/src/github.com/Azure/acs-engine`
|
||||
4. `go build` to build the project
|
||||
5. `./acs-engine` to see the command line parameters
|
||||
|
||||
|
||||
# Template Generation
|
||||
|
||||
The `acs-engine` takes a json [cluster definition file](clusterdefinition.md) as a parameter and generates 3 or more of the following files:
|
||||
|
||||
1. **apimodel.json** - this is the cluster configuration file used for generation
|
||||
2. **azuredeploy.json** - this is the main ARM (Azure Resource Model) template used to deploy a full Docker enabled cluster
|
||||
3. **azuredeploy.parameters.json** - this is the parameters file used along with azurdeploy.json during deployment and contains configurable parameters
|
||||
4. **certificate and access config files** - some orchestrators like Kubernetes require certificate generation, and these generated files and access files like the kube config files are stored along side the model and ARM template files.
|
||||
|
||||
As a rule of thumb you should always work with the `apimodel.json` when modifying an existing running deployment. This ensures that all the same settings and certificates are correctly preserved. For example, if you want to add a second agent pool, you would edit `apimodel.json` and then run `acs-engine` against that file to generate the new ARM templates. Then during deployment all existing deployments remain untouched, and only the new agent pools resources are created.
|
||||
|
||||
# Generating a template
|
||||
|
||||
Here is an example of how to generate a new deployment. This example assumes you are using [examples/kubernetes.json](../examples/kubernetes.json).
|
||||
|
||||
1. Before starting ensure you have generated a valid [SSH Public/Private key pair](ssh.md#ssh-key-generation).
|
||||
2. edit [examples/kubernetes.json](../examples/kubernetes.json) and fill in the blanks.
|
||||
3. run `./acs-engine generate examples/kubernetes.json` to generate the templates in the _output/Kubernetes-UNIQUEID directory. The UNIQUEID is a hash of your master's FQDN prefix.
|
||||
4. now you can use the `azuredeploy.json` and `azuredeploy.parameters.json` for deployment as described in [deployment usage](../README.md#deployment-usage).
|
||||
|
||||
# Deploying templates
|
||||
|
||||
For deployment see [deployment usage](../README.md#deployment-usage).
|
||||
|
|
|
@ -70,7 +70,7 @@ function generate_template() {
|
|||
jqi "${FINAL_CLUSTER_DEFINITION}" ".properties.windowsProfile.secrets[0].vaultCertificates[0].certificateStore = \"My\""
|
||||
fi
|
||||
# Generate template
|
||||
"${DIR}/../acs-engine" generate --output-directory "${OUTPUT}" "${FINAL_CLUSTER_DEFINITION}" --debug
|
||||
"${DIR}/../bin/acs-engine" generate --output-directory "${OUTPUT}" "${FINAL_CLUSTER_DEFINITION}" --debug
|
||||
|
||||
# Fill in custom hyperkube spec, if it was set
|
||||
if [[ ! -z "${CUSTOM_HYPERKUBE_SPEC:-}" ]]; then
|
||||
|
|
|
@ -0,0 +1,28 @@
|
|||
MUTABLE_VERSION := canary
|
||||
|
||||
GIT_COMMIT = $(shell git rev-parse HEAD)
|
||||
GIT_SHA = $(shell git rev-parse --short HEAD)
|
||||
GIT_TAG = $(shell git describe --tags --abbrev=0 --exact-match 2>/dev/null)
|
||||
GIT_DIRTY = $(shell test -n "`git status --porcelain`" && echo "dirty" || echo "clean")
|
||||
BUILD = $(shell date +%FT%T%z)
|
||||
|
||||
ifdef VERSION
|
||||
DOCKER_VERSION = $(VERSION)
|
||||
BINARY_VERSION = $(VERSION)
|
||||
endif
|
||||
|
||||
DOCKER_VERSION ?= git-${GIT_SHA}
|
||||
BINARY_VERSION ?= ${GIT_TAG}
|
||||
|
||||
# Only set Version if building a tag or VERSION is set
|
||||
ifneq ($(BINARY_VERSION),)
|
||||
LDFLAGS += -X github.com/Azure/acs-engine/cmd.BuildSHA=${VERSION}
|
||||
LDFLAGS += -X github.com/Azure/acs-engine/cmd.BuildTime=${BUILD}
|
||||
endif
|
||||
|
||||
info:
|
||||
@echo "Version: ${VERSION}"
|
||||
@echo "Git Tag: ${GIT_TAG}"
|
||||
@echo "Git Commit: ${GIT_COMMIT}"
|
||||
@echo "Git Tree State: ${GIT_DIRTY}"
|
||||
@echo "Docker Version: ${DOCKER_VERSION}"
|
Загрузка…
Ссылка в новой задаче