badhouseplants/badhouseplants-net-old
Archived
4
0
Fork 0
Code Issues 7 Pull Requests 2 Actions Packages Projects Releases Activity

Add a spellchecker tool to CI and fix all existing typos.

Browse Source
This commit is contained in:
Nikolai Rodionov
2023-05-02 14:47:34 +02:00
parent 77447a18da
commit 67ff2bbdfd
14 changed files with 241 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
content/posts/argocd-vs-helmfile-application/index.md
View File

@ -65,7 +65,7 @@ But logic would be like this
- Add a new application to the `manifests/$CLUSTER` dir
- Push
- CI/CD
- Since it needs to be `GitOps`, you need to check that charts in the `vendor` dir are up-to-date with `helm-freeze.yaml`. *Because if you updated helm-freeze and forgot to execute `helm-freeze sync`, you will have a contradiction between actual and desired states. That's one of the reasons, why I don't like this kind of vendoring. Either it's an addition step in CI, that is verifying that the manual step was done, or it's an additional work for reviewer. You also can add an action that is going to execute it withing the pipeline and push to your branch, but I'm completely against it. (something for another post maybe)*
- Since it needs to be `GitOps`, you need to check that charts in the `vendor` dir are up-to-date with `helm-freeze.yaml`. *Because if you updated helm-freeze and forgot to execute `helm-freeze sync`, you will have a contradiction between actual and desired states. That's one of the reasons, why I don't like this kind of vendoring. Either it's an addition step in CI, that is verifying that the manual step was done, or it's an additional work for reviewer. You also can add an action that is going to execute it within the pipeline and push to your branch, but I'm completely against it. (something for another post maybe)*
- Then depending on a branch:
- If not `main`
@ -441,7 +441,7 @@ argocd app diff vpa
FATA[0000] rpc error: code = NotFound desc = error getting application: applications.argoproj.io "vpa" not found
```
There is a `--local` option, but it still requires a name ~~(why if there is a name in manfiests 🙃🙃🙃)~~
There is a `--local` option, but it still requires a name ~~(why if there is a name in manifests 🙃🙃🙃)~~
```BASH
# Just testing out
argocd app diff vpa --local ./manifests/cluster2/
@ -543,7 +543,7 @@ Let's try installing apps directly. Remove an app-of-apps from k8s. And let's us
## Conclusion
So you can check the PR here: <https://git.badhouseplants.net/allanger/helmfile-vs-argo/pulls/2/files>
I like that `values` can be handled as normal values files. (But for handling secrets you might have to add a [CMP](https://argo-cd.readthedocs.io/en/stable/user-guide/config-management-plugins/), that means an additional work and maintenance) But even if adding CMP is fine, I couldn't get proper `diffs` for my changes, that means that I can't see what's happening without applying manifests. And applying manifests will mean that other team members will not be work on other tickets withing the same scope, so it looks like a bottleneck to me.
I like that `values` can be handled as normal values files. (But for handling secrets you might have to add a [CMP](https://argo-cd.readthedocs.io/en/stable/user-guide/config-management-plugins/), that means an additional work and maintenance) But even if adding CMP is fine, I couldn't get proper `diffs` for my changes, that means that I can't see what's happening without applying manifests. And applying manifests will mean that other team members will not be work on other tickets within the same scope, so it looks like a bottleneck to me.
But I don't like that you need to add a lot of manifests to manage all the applications. We have only 2 manifests that are copied from folder to folder. So we have a lot of repeating code. And repeating code is never good. So I would write a tool that can let you choose applications from the list of all applications and choose clusters where they need to be deployed. So the config looks like this:
```YAML
@ -565,7 +565,7 @@ But I think that with the whole GitOps pulling concept it will be a hard thing t
I can only say, that I see no profit in using argo like this. It only seems like either a very complicated setup (most probably you will be able to implement anything you need, the question is, how much time will you spend with that), or a ~~crippled~~ not complete setup.
And if you compare an amount of lines that area updadated to install these apps as `Applications` to the helmfile stuff, it's going to be ~100 vs ~30. And that's what I also don't like.
And if you compare an amount of lines that area updated to install these apps as `Applications` to the helmfile stuff, it's going to be ~100 vs ~30. And that's what I also don't like.
In the next post I will try doing the same with `ApplicationSets`, and we'll see, if it looks better or not.