9072f3b980
* build: Build webassets for CentOS 7 with Ubuntu buildbox Build the webassets for the CentOS 7 binaries using the standard Ubuntu buildbox prior to building the binaries. This allows us to use a later version of node.js to build the UI than what is available on CentOS 7. The `release-unix` and `clean` targets need to be rejigged a little as `release-unix` first cleans any pre-build webassets. So we add a new target `release-unix-preserving-webassets` that only cleans the build and not the webassets and update the Makefile in `build.assets` to call this new target when building CentOS 7 binaries. * build: Conditionally build enterprise webassets Only build enterprise webassets if the enterprise submodule is present. For a normal release, this will always be the case, but for local testing and people wishing to build just the OSS release, the enterprise submodule may not be present. * build: Build webassets with buildbox-connect Use the Teleport Connect buildbox for building the webassets. That ensures the same version of node is used for building all the node stuff; the web UI as well as Teleport Connect. It makes maintenance of the buildboxes easier as we can move to using only the one buildbox for node in the future. * build: Pre-build webassets for non-centos7 build targets Add a dependency on `webassets` for the non-centos7 fips build/release targets in build.assets/Makefile. These targets were recently changed to actually use centos7 anyway, so we do need to pre-build webassets as centos7 will soon no longer be able to build them. NOTE: These updated targets should probably be removed. They are effectively duplicates of their centos7 counterparts now and should probably just chain to those targets. The `release-fips` target is actually broken at the moment as it needs to use `scl enable ...` to build now it uses centos7. * Replace "standard Ubuntu buildbox" in comments with buildbox-connect --------- Co-authored-by: Grzegorz Zdunek <grzegorz.zdunek@goteleport.com> Co-authored-by: Grzegorz Zdunek <gzdunek@users.noreply.github.com> |
||
---|---|---|
.. | ||
charts | ||
download-hashes | ||
flake | ||
gpg | ||
macos | ||
pam | ||
pkgconfig | ||
rpm | ||
rpm-sign | ||
tooling | ||
windows | ||
.bashrc | ||
.dockerignore | ||
.gitignore | ||
build-common.sh | ||
build-fido2-macos.sh | ||
build-package.sh | ||
build-pkg-tsh.sh | ||
build-test-compat.sh | ||
build-webassets-if-changed.sh | ||
changelog.sh | ||
Dockerfile | ||
Dockerfile-arm | ||
Dockerfile-centos7 | ||
Dockerfile-centos7-assets | ||
Dockerfile-centos7-fips | ||
Dockerfile-connect | ||
Dockerfile-grpcbox | ||
Dockerfile-multiarch | ||
Dockerfile-multiarch-base | ||
Dockerfile-multiarch-clang | ||
genproto.sh | ||
grpcbox.mk | ||
images.mk | ||
install | ||
keychain-setup.sh | ||
locale.gen | ||
Makefile | ||
profile | ||
README.md | ||
versions.mk |
Dockerized Teleport Build
This directory is used to produce a containerized production Teleport build. No need to have Golang. Only Docker is required.
It is a part of Gravitational CI/CD pipeline. To build Teleport type:
make
Safely updating build box Dockerfiles
The build box images are used in Drone pipelines and GitHub Actions. The resulting image is pushed to Amazon ECR and ghcr.io. This means that to safely introduce changes to Dockerfiles, those changes should be split into two stages:
- First you open a PR which updates a Dockerfile and get the PR merged.
- Once it's merged, Drone is going to pick it up, build a new build box image and push it to Amazon ECR.
- Then you can open another PR which starts using the new build box image.
DynamoDB static binary docker build
The static binary will be built along with all nodejs assets inside the container. From the root directory of the source checkout run:
docker build -f build.assets/Dockerfile.dynamodb -t teleportbuilder .
Then you can upload the result to an S3 bucket for release.
docker run -it -e AWS_ACL=public-read -e S3_BUCKET=my-teleport-releases -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY teleportbuilder
Or simply copy the binary out of the image using a volume (it will be copied to current directory/build/teleport).
docker run -v $(pwd)/build:/builds -it teleportbuilder cp /gopath/src/github.com/gravitational/teleport/teleport.tgz /builds
OS package repo migrations
An OS package repo migration is semi-manually publishing specific releases to the new APT and YUM repos. This is required in several situations:
- A customer requests that we add an older version to the repos
- We add another OS package repo (for example APK)
- A OS package promotion fails (for example https://drone.platform.teleport.sh/gravitational/teleport/14666/1/3), requires a PR to fix, and we don't want to cut another minor version
Multiple migrations can be performed at once. To run a migration do the following:
- Clone https://github.com/gravitational/teleport.git.
- Change to the directory the repo was cloned to.
- Create a new branch from master.
- Add the Teleport versions you wish to migration as demonstrated here:
151a2f489e (diff-2e3a64c97d186491e06fb2c7ead081b7ace2b67c4a4d974a563daf7c117a2c50)
. - Set the
migrationBranch
variable to the name of the branch you created in (3) as demonstrated here:151a2f489e (diff-2e3a64c97d186491e06fb2c7ead081b7ace2b67c4a4d974a563daf7c117a2c50)
. - Get your Drone credentials from here: https://drone.platform.teleport.sh/account.
- Export your drone credentials as shown under "Example CLI Usage" on the Drone account page
- Open a new terminal.
- Run
tsh apps login drone
and follow any prompts. - Run
tsh proxy app drone
and copy the printed socket. This should look something like127.0.0.1:60982
- Switch back to your previous terminal.
- Run
export DRONE_SERVER=http://{host:port}
, replacing{host:port}
with the data you copied in (10) - Run
make dronegen
- Commit the two changed files and push/publish the branch
- Open a PR merging your changes into master via https://github.com/gravitational/teleport/compare
- Under the "checks" section, click "details" on the check labeled "continuous-integration/drone/push"
- Once the pipelines complete, comment out the versions you added and blank out the
migrationBranch
string set in (4, 5) as demonstrated here:9095880560 (diff-2e3a64c97d186491e06fb2c7ead081b7ace2b67c4a4d974a563daf7c117a2c50)
- Run
make dronegen
- Commit and push the changes.
- Merge the PR and backport if required.