brandon/oam
1
0
Fork 0
mirror of https://gitea.com/mcereda/oam.git synced 2026-02-09 05:44:23 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: add findings from various usage

Browse Source
This commit is contained in:
Michele Cereda
2025-03-19 17:42:21 +01:00
parent ee65ec9424
commit e5165a8160
5 changed files with 122 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
knowledge base/cloud computing/aws/codedeploy.md
View File

@@ -17,17 +17,17 @@ Automates application deployments to EC2 and on-premises instances, Lambda funct
Application content can be stored in S3 buckets, or GitHub or Bitbucket repositories.<br/>
No changes are needed to the application itself.
| Component | Summary |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| Application | Name that uniquely identifies the application resources to deploy, and to deploy to. |
| Compute platform | The platform on which applications are deployed an application. |
| Deployment configuration | Set of rules and success/failure conditions used during deployments. |
| Deployment group | Set of individual EC2/on-premise instances to deploy to, if using them. |
| Deployment type | Method used for deployments to instances in a deployment group.<br/>Available deployment types are _in-place_ and _blue/green_. |
| IAM instance profile | IAM role for EC2 instances.<br/>It must have the permissions required to access the application code. |
| Revision | Application versions. |
| Service role | IAM role granting permissions to CodeDeploy to access AWS resources. |
| Target revision | The application revision currently targeted for deployment. |
| Component | Summary |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| Application | Name used as reference to ensure the correct components are chosen during a deployment |
| Compute platform | Platform on which applications are deployed.<br/>Choices include _EC2/On-Premises_, _AWS Lambda_, and _Amazon ECS_. |
| Deployment configuration | Set of rules and success/failure conditions used during deployments |
| Deployment group | Set of tagged EC2/on-premise instances to deploy to, if used |
| Deployment type | How applications are made available to instances in a deployment group.<br/>Choices include _in-place_ and _blue/green_. |
| IAM instance profile | IAM role for EC2 instances.<br/>It must have the permissions required to access the application code. |
| Revision | Application versions |
| Service role | IAM Role used by CodeDeploy to access AWS resources |
| Target revision | Application revision currently targeted for deployment |
<!-- Uncomment if used
<details>
@@ -85,13 +85,13 @@ flowchart LR
One must set up the instances before CodeDeploy can deploy application revisions to them for the first time.
Manually provisioned instances must abide the following:
**Manually** provisioned instances must abide the following:
- The CodeDeploy agent must be present on the instances.
- They must be tagged, if one is using tags to identify instances in a deployment group.<br/>
CodeDeploy relies on tags to identify and group instances into deployment groups.
- They must be launched with an IAM instance profile attached.<br/>
The instance profile enables the CodeDeploy agent to verify the identity of the instance.
The instance profile is required by the CodeDeploy agent to verify the identity of the instance.
- They must be modifiable by the [service role] used by CodeDeploy.
Instances are taken offline during deployments so that the latest application revision can be installed.

92
knowledge base/snowflake.md Normal file
View File

@@ -0,0 +1,92 @@
# Snowflake
> TODO
Intro
<!-- Remove this line to uncomment if used
## Table of contents <!-- omit in toc -->
1. [TL;DR](#tldr)
1. [Snowflake CLI](#snowflake-cli)
1. [Further readings](#further-readings)
1. [Sources](#sources)
## TL;DR
<details>
<summary>Setup</summary>
```sh
# Install Snowflake CLI.
# Get it from the [Snowflake CLI repository].
curl -fsSLO 'https://sfc-repo.snowflakecomputing.com/snowflake-cli/linux_aarch64/3.4.1/snowflake-cli-3.4.1.aarch64.deb' \
&& dpkg -i 'snowflake-cli-3.4.1.aarch64.deb'
curl -fsSLO 'https://sfc-repo.snowflakecomputing.com/snowflake-cli/darwin_arm64/3.4.1/snowflake-cli-3.4.1-darwin-arm64.pkg' \
&& sudo installer -pkg 'snowflake-cli-3.4.1-darwin-arm64.pkg' -target '/'
curl -fsSLO 'https://sfc-repo.snowflakecomputing.com/snowflake-cli/linux_aarch64/3.4.1/snowflake-cli-3.4.1.aarch64.rpm' \
&& rpm -i 'snowflake-cli-3.4.1.rpm'
# Check it works.
snow --help
```
</details>
<!-- Uncomment if used
<details>
<summary>Usage</summary>
```sh
```
</details>
-->
<!-- Uncomment if used
<details>
<summary>Real world use cases</summary>
```sh
```
</details>
-->
## Snowflake CLI
Refer [Snowflake CLI].
Meant to replace the SnowSQL tool.
Download from the [Snowflake CLI repository].
```sh
curl -fsSLO 'https://sfc-repo.snowflakecomputing.com/snowflake-cli/darwin_arm64/3.4.1/snowflake-cli-3.4.1-darwin-arm64.pkg' \
&& sudo installer -pkg 'snowflake-cli-3.4.1-darwin-arm64.pkg' -target '/'
```
## Further readings
- [Website]
### Sources
- [Documentation]
- [Snowflake CLI]
<!--
Reference
═╬═Time══
-->
<!-- In-article sections -->
<!-- Knowledge base -->
<!-- Files -->
<!-- Upstream -->
[documentation]: https://docs.snowflake.com/en/
[website]: https://www.snowflake.com/en/
[snowflake cli]: https://docs.snowflake.com/en/developer-guide/snowflake-cli/index
[snowflake cli repository]: https://sfc-repo.snowflakecomputing.com/snowflake-cli/index.html
<!-- Others -->

15
knowledge base/task.md
View File

@@ -17,6 +17,8 @@ Task runner aiming to be simpler and easier to use than [GNU Make].
Taskfiles are Task's Makefile counterpart.<br/>
Taskfiles are written in YAML.
_Tasks_ in Task are what _targets_ are for Make.
Task leverages `mvdan.cc/sh` to run commands, which is a native Go shell interpreter.<br/>
It allows to write `sh`/`bash` commands and have them work even where `sh` or `bash` are usually not available (e.g.:
Windows) as long as any called executable is available in `PATH`.
@@ -26,9 +28,9 @@ Pros:
- Taskfiles are more readable than Makefiles.
Specifically:
- No need to use tabs.
- No need for special symbols.
- Easier environment variables management.
- There is no need to explicitly use tabs in tasks' definitions.
- There is no need for special symbols, like `@`.
- Environment variables management is easier.
Cons:
@@ -36,7 +38,7 @@ Cons:
That makes them very much similar to \[[Gitlab] / [Azure Devops]]'s pipelines, and if one has any experience with them
one knows what a pain that can be.
Uses Go's [text/template] package to interpolate values.
Uses Go's [text/template] and [slim-sprig] packages to interpolate values.
Environment variables (`env: {}, dotenv: []`) are available in the shell used by commands.<br/>
Variables (`vars: {}`) are **only** available to Task while executing templates, but **will default to environment
@@ -96,7 +98,7 @@ task --dry --verbose 'lint' 'validate:ansible'
task --dry 'bootstrap'
```
If task names are omitted, a task named `default` will be assumed.
If task names are omitted, Task will try and execute a task named `default`.
## Variables
@@ -260,12 +262,12 @@ Force the print using `-v, --verbose` when `silent` is set to `true`, or set it
- [Website]
- [Github]
- [Demystification of taskfile variables]
### Sources
- [Usage]
- [Stop Using Makefile (Use Taskfile Instead)]
- [Demystification of taskfile variables]
<!--
Reference
@@ -286,5 +288,6 @@ Force the print using `-v, --verbose` when `silent` is set to `true`, or set it
<!-- Others -->
[demystification of taskfile variables]: https://medium.com/@TianchenW/demystification-of-taskfile-variables-29b751950393
[slim-sprig]: https://github.com/go-task/slim-sprig
[stop using makefile (use taskfile instead)]: https://dev.to/calvinmclean/stop-using-makefile-use-taskfile-instead-4hm9
[text/template]: https://pkg.go.dev/text/template

3
snippets/aws/other commands.fish
View File

@@ -362,6 +362,9 @@ aws kms decrypt --key-id 'arn:aws:kms:eu-west-1:123456789012:key/d74f5077-811b-4
--output 'text' --query 'Plaintext' \
| base64 --decode > 'decryptedKey.bin'
aws kms list-aliases --query 'Aliases[?AliasName.contains(@,`staging`)]'
aws kms list-aliases --query 'Aliases[?AliasName.contains(@,`prod`)]|[*].{"Alias":@.AliasName,"KeyId":@.TargetKeyId}'
###
# RDS

5
snippets/kubectl.sh
View File

@@ -74,3 +74,8 @@ kubectl get --raw "/api/v1/nodes/ip-172-31-69-42.eu-west-1.compute.internal/prox
# Get ephemeral storage usage for pods
kubectl get --raw "/api/v1/nodes/ip-172-31-69-42.eu-west-1.compute.internal/proxy/stats/summary" \
| jq '.pods[] | select(.podRef.name == "gitlab-runner-59dd68c5cb-9vcp4")."ephemeral-storage"'
# Dynamic way for the same action
POD_NAME='gitlab-runner-6ddd58fcb6-c9swk' POD_NAMESPACE='gitlab' \
&& kubectl get pods -n "$POD_NAMESPACE" "$POD_NAME" -o jsonpath='{.status.hostIP}' | tr '.' '-' \
| xargs -I '%%' kubectl get --raw '/api/v1/nodes/ip-%%.eu-west-1.compute.internal/proxy/stats/summary' \
| jq --arg 'podName' "$POD_NAME" '.pods[] | select(.podRef.name == $podName)."ephemeral-storage"'