Skip to content

Commit

Permalink
Set up link checker + GH action + fix links
Browse files Browse the repository at this point in the history
Signed-off-by: Patrice Chalin <[email protected]>
  • Loading branch information
chalin committed Jun 8, 2024
1 parent ac0d758 commit 4cf2a80
Show file tree
Hide file tree
Showing 12 changed files with 139 additions and 32,616 deletions.
18 changes: 18 additions & 0 deletions .github/workflows/check-links.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
name: Links

on:
pull_request:

jobs:
build-and-check-links:
name: CHECK LINKS
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version-file: .nvmrc
cache: npm
cache-dependency-path: package.json
- run: npm install --omit=optional
- run: npm run check:links
10 changes: 6 additions & 4 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -1,10 +1,12 @@

public/
resources/
node_modules/
.hugo_build.lock
.DS_Store
.hugo_build.lock
/public
/resources
node_modules/
package-lock.json
pagefind
tmp/

# Local Netlify folder
.netlify
8 changes: 8 additions & 0 deletions .htmltest.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# cSpell:ignore pagefind regexs
DirectoryPath: public
# IgnoreDirectoryMissingTrailingSlash: true # FIXME
IgnoreInternalEmptyHash: true # FIXME
IgnoreDirs:
- ^(bn|de|es|fr|hi|it|ja|ko|pt.*?|ru|tr|ur|zh.*?)/
IgnoreURLs: # list of regexs of paths or URLs to be ignored
- ^/pagefind
1 change: 1 addition & 0 deletions .nvmrc
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
lts/*
33 changes: 27 additions & 6 deletions Makefile
Original file line number Diff line number Diff line change
@@ -1,5 +1,27 @@
HTMLTEST_DIR=tmp
HTMLTEST?=htmltest # Specify as make arg if different
HTMLTEST_ARGS?=--skip-external

# Use $(HTMLTEST) in PATH, if available; otherwise, we'll get a copy
ifeq (, $(shell which $(HTMLTEST)))
override HTMLTEST=$(HTMLTEST_DIR)/bin/htmltest
ifeq (, $(shell which $(HTMLTEST)))
GET_LINK_CHECKER_IF_NEEDED=get-link-checker
endif
endif

check-links: $(GET_LINK_CHECKER_IF_NEEDED)
$(HTMLTEST) $(HTMLTEST_ARGS)

clean:
rm -rf $(HTMLTEST_DIR) public/* resources

get-link-checker:
rm -Rf $(HTMLTEST_DIR)/bin
curl https://htmltest.wjdp.uk | bash -s -- -b $(HTMLTEST_DIR)/bin

serve:
hugo server \
npx hugo server \
--disableFastRender \
--buildDrafts \
--buildFuture \
Expand All @@ -13,16 +35,15 @@ serve:
--gc

production-build:
git submodule update --init --recursive
hugo \
--minify
npm run get:submodule
npx hugo --minify
npx -y pagefind --site public

preview-build:
git submodule update --init --recursive
hugo \
npx hugo \
--baseURL $(DEPLOY_PRIME_URL) \
--buildDrafts \
--buildFuture \
--minify
npx -y pagefind --site public
npx -y pagefind --site public
24 changes: 11 additions & 13 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,19 +13,19 @@ If you'd like to help with the glossary we'd love to have your contributions! Pl
## Acknowledgements

The Cloud Native Glossary was initiated by the CNCF Marketing Committee
(Business Value Subcommittee) and includes contributions from
[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/),
[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/),
[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk),
[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/),
[Katelin Ramer](https://www.linkedin.com/in/katelinramer/),
[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca),
and many more contributors.
(Business Value Subcommittee) and includes contributions from
[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/),
[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/),
[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk),
[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/),
[Katelin Ramer](https://www.linkedin.com/in/katelinramer/),
[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca),
and many more contributors.
For a complete contributor list, please refer to [this GitHub page](https://github.com/cncf/glossary/graphs/contributors).

The Glossary is maintained by
The Glossary is maintained by
[Seokho Son](https://www.linkedin.com/in/seokho-son/),
[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/),
[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/),
[Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/),
[Nate W.](https://www.linkedin.com/in/nate-double-u/),
and [Jorge Castro](https://www.linkedin.com/in/jorge-castro2112/).
Expand All @@ -43,10 +43,8 @@ All code contributions are under the Apache 2.0 license. Documentation is distri

To improve the Cloud Native Glossary site itself, install a local copy with these instructions. Note you must have [npm](https://www.npmjs.com/) and [Hugo](https://gohugo.io/) installed.

```
```sh
git clone https://github.com/cncf/glossary.git
cd glossary
git submodule update --init --recursive
npm install
```

Expand Down
16 changes: 8 additions & 8 deletions content/en/container-orchestration.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,19 +4,19 @@ status: Completed
category: Concept
---

[Container](/container/) orchestration refers to managing and automating the lifecycle of [containerized](/containerization/) applications in dynamic environments.
It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes)), which enables deployments, (auto)scaling, auto-healing, and monitoring.
[Container](/container/) orchestration refers to managing and automating the lifecycle of [containerized](/containerization/) applications in dynamic environments.
It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes/)), which enables deployments, (auto)scaling, auto-healing, and monitoring.
Orchestration is a metaphor:
The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should.
The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should.

## Problem it addresses
## Problem it addresses

Managing [microservices](/microservices), security, and network communication at scale — and [distributed systems](/distributed-systems) in general — is hard, if not impossible, to manage manually.
Container orchestration allows users to automate all these management tasks.
Managing [microservices](/microservices-architecture/), security, and network communication at scale — and [distributed systems](/distributed-systems/) in general — is hard, if not impossible, to manage manually.
Container orchestration allows users to automate all these management tasks.

## How it helps

Container orchestration tools allow users to determine a system's state.
Container orchestration tools allow users to determine a system's state.
First, they declare how it should look like (e.g., x containers, y pods, etc.).
The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes).
The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes).
This automation simplifies many of the engineering teams' otherwise highly manual and complex operational tasks, including provisioning, deployment, scaling (up and down), networking, load balancing, and other activities.
20 changes: 10 additions & 10 deletions content/en/loosely-coupled-architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,15 @@ category: Property
tags: ["fundamental", "architecture", "property"]
---

Loosely coupled architecture is an architectural style
where the individual components of an application are built independently from one another
(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architectures/)).
Each component, sometimes referred to as a [microservice](/microservices-architecture/), is built to perform a specific function
in a way that can be used by any number of other services.
This pattern is generally slower to implement than tightly coupled architecture
Loosely coupled architecture is an architectural style
where the individual components of an application are built independently from one another
(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architecture/)).
Each component, sometimes referred to as a [microservice](/microservices-architecture/), is built to perform a specific function
in a way that can be used by any number of other services.
This pattern is generally slower to implement than tightly coupled architecture
but has a number of benefits, particularly as applications scale.

Loosely coupled applications allow teams to develop features, deploy, and scale independently,
which allows organizations to iterate quickly on individual components.
Application development is faster and teams can be structured around their competency,
focusing on their specific application.
Loosely coupled applications allow teams to develop features, deploy, and scale independently,
which allows organizations to iterate quickly on individual components.
Application development is faster and teams can be structured around their competency,
focusing on their specific application.
32 changes: 16 additions & 16 deletions content/en/microservices-architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,31 +5,31 @@ tags: ["architecture", "fundamental", ""]
---

A microservices architecture is an architectural approach that breaks applications into individual independent (micro)[services](/service/), with each service focused on a specific functionality.
These services work together closely, appearing to the end user as a single entity.
Take Netflix as an example.
Its interface allows you to access, search, and preview videos.
These services work together closely, appearing to the end user as a single entity.
Take Netflix as an example.
Its interface allows you to access, search, and preview videos.
These capabilities are likely powered by smaller services that each handle one functionality, e.g., authentication, search, and running previews in your browser.

This architectural approach allows developers to push out new features or update functionality much faster than if they were all tightly coupled, such as in a [monolithic application](/monolithic-apps/) (more to that below).

## Problem it addresses

Applications are made up of different parts, each responsible for a specific capability.
Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts.
Going back to our Netflix example.
Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day.
The surge in signups demands more signup capacity.
Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources.
Applications are made up of different parts, each responsible for a specific capability.
Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts.
Going back to our Netflix example.
Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day.
The surge in signups demands more signup capacity.
Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources.

Monolithic architectures also make it easy for developers to succumb to design pitfalls.
Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architectures/) and harder to enforce the principle of separation of concerns.
Monoliths also often require developers to understand the entire codebase before deploying any changes.
Microservices architecture is a response to these challenges.
Monolithic architectures also make it easy for developers to succumb to design pitfalls.
Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architecture/) and harder to enforce the principle of separation of concerns.
Monoliths also often require developers to understand the entire codebase before deploying any changes.
Microservices architecture is a response to these challenges.


## How it helps

Separating functionality into different microservices makes them easier to deploy, update, and scale independently.
It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app.
While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude.
Separating functionality into different microservices makes them easier to deploy, update, and scale independently.
It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app.
While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude.
Many [cloud-native technologies](/cloud-native-tech/) aim to make microservices easier to deploy and manage.
10 changes: 5 additions & 5 deletions content/en/stateful-apps.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,12 +5,12 @@ category: Property
tags: ["fundamental", "application", "property"]
---

When we speak of stateful (and [stateless](/stateless-apps/)) apps,
state refers to any data the app needs to store to function as designed.
Any kind of online shop that remembers your cart is a stateful app for example.
When we speak of stateful (and [stateless](/stateless-apps/)) apps,
state refers to any data the app needs to store to function as designed.
Any kind of online shop that remembers your cart is a stateful app for example.

Today, most applications we use are at least partly stateful. In cloud native environments though,
stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps) are very dynamic.
Today, most applications we use are at least partly stateful. In cloud native environments though,
stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps/) are very dynamic.
They can be scaled up and down, restarted, and moved around but still need to be able to access their state.

Therefore, stateful apps needs some kind of storage that is accessible from anywhere, like databases.
Loading

0 comments on commit 4cf2a80

Please sign in to comment.