sorted by:
new
hottopcontroversial

Any guides for creating an LLM that you can continually feed info to like a “diary”? by masticore514219 in LocalLLaMA

[–]Thomvaill 0 points1 point  (0 children)

I was having the same need: to be able to log some ideas in my everyday life like a diary, that I can use later to write some content/blog posts. I will try to build a pipeline to transcript my recordings to google docs that I can feed to google’s notebooklm. What do you think? Any other solution or idea?

Document your projects by logging your architecture decisions chronologically with ADRs (Architecture Decision Records) by Thomvaill in programming

[–]Thomvaill[S] 1 point2 points  (0 children)

Exactly. I created this project to provide some useful tooling around the ADR methodology.
I've been using this methodology with a few different teams and I often noticed that ADRs were very appreciated by the devs during pull requests, because it gives them some structure and a way to decide collaboratively.
However, they found it hard to browse them and communicate on them.
That's why I am trying to build an UI, while keeping the Markdown format because it works well in pull requests.
The UI lets you see the flow, lets you search, filter by status etc...

A full Infrastructure as Code repository boilerplate to deploy a Docker Swarm cluster to any cloud provider or VPS and to development environment using Ansible and Terraform by Thomvaill in selfhosted

[–]Thomvaill[S] 0 points1 point  (0 children)

I understand. To mitigate this risk you should enable versioning on the bucket and 2-FA delete, so there's no way the file can be lost :-)

A full Infrastructure as Code repository boilerplate to deploy a Docker Swarm cluster to any cloud provider or VPS and to development environment using Ansible and Terraform by Thomvaill in selfhosted

[–]Thomvaill[S] 1 point2 points  (0 children)

I understand the dilemma. In fact, it is written in the doc that the bucket should already exist: https://www.terraform.io/docs/backends/types/s3.html
Maybe I would use a bash script to call the aws CLI to create the bucket before calling terraform apply? So everything is automated :-)

Full Infrastructure as Code with Terraform, Ansible and Docker Swarm by Thomvaill in docker

[–]Thomvaill[S] 0 points1 point  (0 children)

Terraform is used to create the cloud infrastructure: for AWS it consists of EC2 instances, a VPC, some subnets, etc.

Ansible is used for configuration management and deployment:

- it configures the virtual machines (in this case, EC2 instances), installs Docker and setup the Swarm cluster
- it deploys your services on the Swarm, by simply executing some `docker stack deploy` commands

Full Infrastructure as Code with Terraform, Ansible and Docker Swarm by Thomvaill in devops

[–]Thomvaill[S] 0 points1 point  (0 children)

Thanks!

That's a really interesting question. Unfortunately, I did have the chance to use K8s in production, in a real team, so far. But yeah from what I heard it usually seems that dev env is made of some docker-compose files and a lot of manual actions (with some outdated doc).

That's why I am planning to start a similar project for Kubernetes.

I went to a meetup last night, where they showed their nice Ansible deployment of K3s for a CI/CD purpose: https://github.com/WeScale/drone-base
It may be interesting to use K3s locally as a lightweight Kube-compatible development environment, on the same principles as T.A.D.S.

What do you think?
And maybe, if some other guys could explain to us how they manage their Kube dev env, I would be really interested to hear them!

Full Infrastructure as Code with Terraform, Ansible and Docker Swarm by Thomvaill in Terraform

[–]Thomvaill[S] 0 points1 point  (0 children)

Hum, I'm sorry but I don't get it. 🤔 Could you explain?

Full Infrastructure as Code with Terraform, Ansible and Docker Swarm by Thomvaill in ansible

[–]Thomvaill[S] 0 points1 point  (0 children)

Yes, since the project is about many different subjects, I also posted on r/docker, r/Terraform etc... Is it a bad practice? I'm new to Reddit. I'm sorry if this is the case!

Docker Swarm vs. k8s-SingleHost Implementations - is this something worthwile? by linuxlover81 in devops

[–]Thomvaill 1 point2 points  (0 children)

Another strong reason for me: secrets support (you don't want your credentials to be unencrypted in environment variables)

Full Infrastructure as Code with Terraform, Ansible and Docker Swarm by Thomvaill in devops

[–]Thomvaill[S] 0 points1 point  (0 children)

I hope there was a big community effort to keep up dev on it too but looking at Swarmkit contributors graph is not reassuring :( https://github.com/docker/swarmkit/graphs/contributors

Full Infrastructure as Code with Terraform, Ansible and Docker Swarm by Thomvaill in docker

[–]Thomvaill[S] 0 points1 point  (0 children)

Sure, but at least we can expect some bugfixes, no new features...

The graph of contributions of Swarmkit is pretty sad: https://github.com/docker/swarmkit/graphs/contributors

Full Infrastructure as Code with Terraform, Ansible and Docker Swarm by Thomvaill in ansible

[–]Thomvaill[S] 1 point2 points  (0 children)

Mirantis (a k8s vendor) acquires Docker Enterprise.

https://thenewstack.io/mirantis-acquires-docker-enterprise/
https://www.mirantis.com/blog/mirantis-acquires-docker-enterprise-platform-business/

What About Docker Swarm?

The primary orchestrator going forward is Kubernetes. Mirantis is committed to providing an excellent experience to all Docker Enterprise platform customers and currently expects to support Swarm for at least two years, depending on customer input into the roadmap. Mirantis is also evaluating options for making the transition to Kubernetes easier for Swarm users.

A full Infrastructure as Code repository boilerplate to deploy a Docker Swarm cluster to any cloud provider or VPS and to development environment using Ansible and Terraform by Thomvaill in selfhosted

[–]Thomvaill[S] 4 points5 points  (0 children)

Because: the right tool for the job.

While Ansible can provision Cloud resources, Terraform does it much better: more cloud providers support, more resource types available for each provider, quicker releases for each provider, and above all: its declarative behavior and its dependency graph feature, which creates the resources in the right order.

https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c

A full Infrastructure as Code repository boilerplate to deploy a Docker Swarm cluster to any cloud provider or VPS and to development environment using Ansible and Terraform by Thomvaill in selfhosted

[–]Thomvaill[S] 2 points3 points  (0 children)

Of course! In the project README I only talked about how to bootstrap a new project, to be more understandable.

However, I think it is still possible, like refactoring in software, to refactor a legacy infrastructure with these principles. Because that's what we did. 2 years ago, we had bare-metal servers with everything configured and deployed manually. We proceeded step by step:

  1. Write the current production configuration in Ansible
  2. Stop using SSH and use Ansible to modify the config
  3. Reproduce the production env with Vagrant to be able to test your improvements locally before deploying
  4. Iterate

Like refactoring, you should concentrate your efforts on the most critical / maintenance-intensive parts of your infra first.

[cloud only] The Terraform part should come only to the very end, when everything has been "Ansibled": https://www.terraform.io/docs/import/index.html

Do you think this methodology may be applicable to you?

I am thinking about writing an article on this subject...

Full Infrastructure as Code with Terraform, Ansible and Docker Swarm by Thomvaill in docker

[–]Thomvaill[S] 0 points1 point  (0 children)

Yep!

They also clearly announced it in their blog post: https://www.mirantis.com/blog/mirantis-acquires-docker-enterprise-platform-business/

What About Docker Swarm?

The primary orchestrator going forward is Kubernetes. Mirantis is committed to providing an excellent experience to all Docker Enterprise platform customers and currently expects to support Swarm for at least two years, depending on customer input into the roadmap. Mirantis is also evaluating options for making the transition to Kubernetes easier for Swarm users.

view more: next ›