
早前,GitHub 发布 GitHub Actions 项目,开发者可通过 GitHub Actions 存储和搜索代码,部分代码可直接运行。本文尝试使用 AWS Lambda 和 API Gateway 作为基本 API,编写应用程序原型并用名为 gourmet 的容器运行函数,虽然这可能不会让代码易于管理,但至少不需要写 API 或者 Web 应用程序。
正如 Lambda 函数在 AWS 中运行一样,Github Actions 是一种强大的管理方式,可直接扩展应用。使用 AWS Lambda,可将代码挂接到几乎任何事件上,比如 EC2 创建、终止、DNS 记录更改等,不需要运行服务器,只需加载代码就能正常工作。
本文作者针对此做了一些尝试,但需要 CI 服务器。为了拥有可测试的 kubernetes 集群,作者自建私有存储库,目前因内部有些混乱暂不准备开源。
无论如何,以下是项目文件夹:
├── .github
│ ├── actions
│ │ ├── deploy
│ │ │ ├── deploy
│ │ │ └── Dockerfile
│ │ └── dryrun
│ │ ├── Dockerfile
│ │ └── dryrun
│ └── main.workflow
└── kubernetes
├── digitalocean.yaml
├── external-dns.yaml
├── micro.yaml
├── namespaces.yaml
├── nginx.yaml
└── openvpn.yaml
kubernetes 目录包含集群安装的所有东西。对于此存储库的每次新推送,需要检查是否可用命令 kubectl apply -f./kubernetes --dryrun 将其应用于 kubernetes 集群,并且当合并 PR 时,应用更改。
因此,作者在.github/main.workflow 中创办了工作流:
## Workflow defines what we want to call a set of actions.
## For every new push check if the changes can be applied to kubernetes ## using the action called: kubectl dryrun
workflow "after a push check if they apply to kubernetes" {
on = "push"
resolves = ["kubectl dryrun"]
}
## When a PR is merged trigger the action: kubectl deploy. To apply the new code to master.
workflow "on merge to master deploy on kubernetes" {
on = "pull_request"
resolves = ["kubectl deploy"]
}
## This is the action that checks if the push can be applied to kubernetes
action "kubectl dryrun" {
uses = "./.github/actions/dryrun"
secrets = ["KUBECONFIG"]
}
## This is the action that applies the change to kubernetes
action "kubectl deploy" {
uses = "./.github/actions/deploy"
secrets = ["KUBECONFIG"]
}
secrets 是一组环境变量,可从外部设置值。如果帐户启用 GitHub Action,则每个存储库的 Setting 都会有一个名为 secrets 的新标签。
本例,作者将 KUBECONFIG 设置为 kubeconfig 文件的 base64,允许 GitHub Action 授权给 Kubernetes 集群。
两个操作类似,第一个操作位于 .github/actions/dryrun 目录:
├── .github
├── actions
└── dryrun
├── Dockerfile
└── dryrun
包含一个 Dockerfile
FROM alpine:latest
## The action name displayed by GitHub
LABEL "com.github.actions.name"="kubectl dryrun"
## The description for the action
LABEL "com.github.actions.description"="Check the kubernetes change to apply."
## https://developer.github.com/actions/creating-github-actions/creating-a-docker-container/#supported-feather-icons
LABEL "com.github.actions.icon"="check"
## The color of the action icon
LABEL "com.github.actions.color"="blue"
RUN apk add --no-cache \
bash \
ca-certificates \
curl \
git \
jq
RUN curl -L -o /usr/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v1.13.0/bin/linux/amd64/kubectl && \
chmod +x /usr/bin/kubectl && \
kubectl version --client
COPY dryrun /usr/bin/dryrun
CMD ["dryrun"]
如上所示,只需要一个 Dockerfile,工作原理和 docker 类似。Cmd dryrun 在这里是复制的 bash 脚本:
#!/bin/bash
main(){
echo ">>>> Action started"
# Decode the secret passed by the action and paste the config in a file.
echo $KUBECONFIG | base64 -d > ./kubeconfig.yaml
echo ">>>> kubeconfig created"
# Check if the kubernetes directory has change
diff=$(git diff --exit-code HEAD~1 HEAD ./kubernetes)
if [ $? -eq 1 ]; then
echo ">>>> Detected a change inside the kubernetes directory"
# Apply the changes with --dryrun just to validate them
kubectl apply --kubeconfig ./kubeconfig.yaml --dry-run -f ./kubernetes
else
echo ">>>> No changed detected inside the ./kubernetes folder. Nothing to do."
fi
}
main "$@"
第二个操作和此几乎一样,Dockerfile 是相同的,但 CMD 看起来是这样的:
#!/bin/bash
main(){
# Decode the secret passed by the action and paste the config in a file.
echo $KUBECONFIG | base64 -d > ./kubeconfig.yaml
# Check if it is an event generated by the PR is a merge
merged=$(jq --raw-output .pull_request.merged "$GITHUB_EVENT_PATH")
# Retrieve the base branch for the PR because I would like to apply only PR merged to master
baseRef=$(jq --raw-output .pull_request.base.ref "$GITHUB_EVENT_PATH")
if [[ "$merged" == "true" ]] && [[ "$baseRef" == "master" ]]; then
echo ">>>> PR merged into master. Shipping to k8s!"
kubectl apply --kubeconfig ./kubeconfig.yaml -f ./kubernetes
else
echo ">>>> Nothing to do here!"
fi
}
main "$@"
除此之外,工作流文件还有一个生成器,似乎效果不错。secrets 允许开箱即用,并与第三方服务集成,也可用 bash 做任何想做的事情!
参考链接:https://gianarb.it/blog/kubernetes-github-action
更多内容推荐
快速构建持续交付系统(四):Ansible 解决自动部署问题
在今天这篇文章中,我主要基于Ansible系统的能力,和你分享了搭建一套部署系统的过程。
2018-09-27
Codefresh 发布 Kubernetes CLI
无
Octokit.NET 允许将 GitHub 集成进.NET Framework 4.5 应用程序中
GitHub发布了Octokit.NET,允许开发者将GitHub API集成进.NET Framework 4.5应用程序中。它还包含访问GitHub API的集成测试。
为所有 PHP-FPM 容器构建单独的 NGinx Dock 镜像
在该文中,作者介绍了自己在PHP应用中,给容器构建NGinx镜像使用的三种方法,即每个API一个NGinx镜像,所有API共用1个NGinx镜像及最终采用的方法定制解决方案。文中列出了部分配置和代码,可供读者参考。
Spark 的运行环境安装:Standalone 入门实战
2020-11-02
OpenSource,使用 Kubeless 在 AWS 上的 Kubernetes 集群中运行 FaaS
借助无服务器计算技术,无需预置、扩展或管理任何服务器即可构建和运行应用程序和服务。
混合云环境中扩展 Kubernetes 的挑战及方案
本文来自RancherLabs微信公众号
Nodejs+Redis 实现简易消息队列
消息队列是存储数据的一个中间件,可以理解为一个容器。生产者生产消息投递 到队列中,消费者可以拉取消息进行消费,如果消费者目前没有消费的打算,则消息队列会保留消息,直到消费者有消费的打算。
2023-02-27
35|秒级开发体验,如何实现容器热加载和一键调试?
这节课,我们来学习如何借助 Nocalhost 实现 Kubernetes 应用秒级的开发体验,提升开发循环反馈效率。
2023-02-27
在 Amazon EKS 上使用 Open Policy Agent
Open Policy Agent (OPA) 是云原生计算基金会 (CNCF) 的一个沙盒项目,可帮助您针对几乎所有内容实施自动化策略,其工作原理与 AWS Identity and Access Management (IAM) 类似。
所有开源项目免费使用,GitHub 内置 CI/CD 终于来了!
2019年8月8日,GitHub官方博客发文称,程序员期待已久的功能来了,Github Actions终于支持内置CI/CD了,并对所有开源项目免费!目前该功能可以在Beta版本中测试使用,11月13日GitHub Actions 将在 GitHub Universe 上正式发布!
高级属性:应对生产级别的应用,你需要掌握哪些技能?
如果你的工作角色是一个云平台开发者,那么,本节课对你步入函数计算领域或者进一步梳理、补充FaaS形态的Serverless平台的能力,都是一个很好的参考支点。
2022-09-02
消息服务 + Serverless 函数计算如何助力企业降本提效?
作者 | 柳下
2023-01-11
后端 BaaS 化(下):Container Serverless
这一讲介绍FaaS和BaaS依赖的底层实现容器Docker。
2020-05-01
GitHub Actions 的机器学习推理上线,推进测试部署高度自动化
GitHub Actions 集成CI/CD 功能,推进开发编译测试部署流程自动化。
开发容器:可重用的开发环境
开发容器提供了可复制、可重用、简化的开发者体验。这篇文章将带你了解开发容器,包括它们的工作原理、如何最有效地使用它们,以及它们与部署容器的区别。
微软发布 Azure Pipelines,开源项目可无限制使用 CI/CD
微软发布了Azure Pipelines,他们新的CI/CD服务,是Azure DevOps产品的一部分。Azure Pipelines可用于构建、测试和部署工作负载,并可以让各种语言、项目类型和平台协同工作。
为什么说容器的崛起预示着云原生时代到来?
摘要:聊云原生之前,我们不妨从容器技术说起。
2020-10-23
结束语 | 带你整体回顾我们的 Serverless 案例
Serverless+AI/IoT/游戏等等,才应该是我们下一步要探索的方向。
2020-05-13


InfoQ 主编
推荐阅读
电子书

大厂实战PPT下载
换一换 
于洋子 | 虎牙 基础架构团队负责人
刘飞 | 达达集团 前端架构师
李福攀 | 蚂蚁集团 高级技术专家
评论