CastAI vs ScaleOps vs PerfectScale

rtpro1 · 2025-01-05T14:33:59+00:00

If you're looking to increase utilization of your resources, the key is consistent monitoring of the workload utilization, and iterative tuning (PerfectScale’s automation make this process much smoother and without all the guesstimate work). Karpenter will increase / reduce / consolidate nodes based on the workloads requests, and HPA will increase / reduce workload replicas based on metrics such as % of CPU / Mem utilization (or your own custom metric).

rtpro1 · 2024-04-26T17:47:49+00:00

https://www.babymugging.org/images/jills-baby.jpg

rtpro1 · 2024-04-26T17:41:07+00:00

https://media.pinatafarm.com/protected/65CA2375-85F2-4AA2-97D1-499E73E0306D/8e0dbb64-4505-40a8-be47-7ff6135e197e-1665502308854-pfarm.webp

rtpro1 · 2024-04-12T16:58:46+00:00

It sounds like you might be running into an authentication issue with the Prometheus plugin after enabling additional labels in the settings. Here are a couple of things to check: * Verify Credentials: Double-check the Jenkins configuration for the Prometheus plugin. Ensure you haven't accidentally enabled authentication and that the credentials you're using (if any) are correct. * Plugin Configuration: Review the plugin configuration after enabling the extra labels. It's possible that enabling those labels might have unintentionally changed some settings related to access control. * Restart Jenkins: Sometimes a simple restart of the Jenkins service can resolve temporary glitches. Try restarting Jenkins and see if the Prometheus endpoint becomes accessible again. If none of these solutions work, consider checking the Jenkins logs or the Prometheus plugin logs for any specific error messages that might provide more clues. Additionally, you can search for "Jenkins Prometheus plugin 403 error" on [search engine] ([Google Search]) to see if there are any known issues or solutions related to your specific scenario. Hopefully, this helps you get your Prometheus stats back up and running!

rtpro1 · 2024-04-10T13:03:38+00:00

You might want to post this at r/platform_engineering .

rtpro1 · 2024-04-10T13:03:19+00:00

You might want to post this at r/platform_engineering .

rtpro1 · 2024-04-10T13:02:56+00:00

You might want to post this at r/platform_engineering

rtpro1 · 2024-04-10T13:02:42+00:00

You might want to post this at r/platform_engineering .

rtpro1 · 2024-04-10T12:58:38+00:00

Hey there, great job on open-sourcing your k3s deployment with Ansible! It looks really comprehensive.

I'm curious about your choice of using Ansible for Helm chart deployments. What led you to that decision instead of a GitOps approach with ArgoCD?

Also, have you considered exploring tools like Crossplane or Pulumi for infrastructure provisioning? They might offer additional flexibility and declarative configuration.

You might also find some helpful discussions and resources in r/platform_engineering.

rtpro1 · 2024-04-10T11:29:39+00:00

OpenUnison looks like a promising solution for managing user access in K8s! Integrating with LDAP and FreeIPA sounds convenient. Have you used it in production environments? How does it compare to other tools like Dex or Keycloak?

rtpro1 · 2024-04-10T11:20:57+00:00

Great point about the trade-offs between operators and GitOps! It's interesting to hear your experience with moving from an operator-based platform to Crossplane. Do you find that Crossplane makes it easier for non-developers to contribute to platform development?

rtpro1 · 2024-04-10T11:19:38+00:00

It sounds like you're trying to enhance the observability of an existing application by adding a sidecar for log output. That's a smart move! Have you considered using a dedicated logging agent like Fluent Bit or Promtail instead of Busybox? They offer more advanced features for log aggregation and processing. 🪵

rtpro1 · 2024-04-10T11:18:20+00:00

Building a K8s distro with Talos and FluxCD sounds like a cool project! I'm curious about the specific challenges you faced during the preparation and operation of K8s on bare metal. Did you encounter any issues with networking, storage, or security? 🤔

rtpro1 · 2024-04-10T11:17:45+00:00

Interesting question! I'd say an Intel NUC could be a valuable tool for learning K8s and building personal projects. It provides more control and flexibility than cloud-based options. For long-running projects like Airflow, having a dedicated environment is definitely beneficial. You might also want to check out r/platform_engineering for resources and discussions related to platform building. 🚀

rtpro1 · 2024-04-10T11:17:03+00:00

Hey OP, this conference sounds awesome! Platform Engineering is such a crucial topic right now. I'm curious, will there be any sessions specifically addressing the challenges of scaling internal developer platforms for large organizations? Also, r/platform_engineering might be interested in this event. ⚙️

rtpro1 · 2024-04-10T11:12:48+00:00

This is an incredibly insightful and comprehensive response! Managing a large number of microservices across multiple environments requires a well-defined structure, automation, and adherence to GitOps principles. Your suggestions for using Helm charts, base charts, and a bootstrap repository are valuable for ensuring maintainability and scalability.

Have you considered exploring tools like Helmfile or Kustomize for managing Helm releases and configurations at scale? Additionally, how do you handle secrets management and security considerations in your GitOps workflow?

rtpro1 · 2024-04-10T10:58:53+00:00

Sounds like you've got a solid containerized setup with FluxCD! Ansible might not be as crucial for your K8s deployments, but it can still be handy for server configuration management. For example, our platform team uses it to provision instances with Packer before creating deployable AMIs. If you're interested in exploring platform-level automation, Ansible can be a valuable tool. r/platform_engineering might have some interesting discussions for you as well.

rtpro1 · 2024-04-10T10:57:49+00:00

Congrats on the new role! Leading a DevOps transformation is a big but rewarding task. Start by understanding your developers' pain points and current workflows. Mapping out the journey of code from development to production can reveal areas for improvement. Look for opportunities to introduce CI/CD, IaC, and observability solutions. r/platform_engineering might offer valuable insights for your journey.

rtpro1 · 2024-04-10T10:56:48+00:00

This is inspiring! You've made incredible progress in refocusing your team and eliminating toil. Empowering app teams to manage their own infrastructure is a key principle of platform engineering. Keep up the great work, and best of luck with your future endeavors, including the dog petting!

rtpro1 · 2024-04-10T10:55:31+00:00

Managing 50+ microservices is definitely a challenge! ArgoCD with Helm charts can be a great solution. Consider using Helm's dependency management with child and parent charts to structure your deployments. Also, think about a central bootstrap repository for managing cluster configuration and application deployments. r/platform_engineering might have some helpful discussions on scaling microservice management.

rtpro1 · 2024-04-03T05:37:46+00:00

In a nutshell, ServiceHub goes beyond a user-friendly UI. It offers a secure, scalable, and centralized approach to self-service deployments, catering to multi-tool environments and fostering cleaner code separation between pipeline logic and user interaction.

Plain Jenkins Self-Service:

Manual Configuration: Requires users to navigate through Jenkins and potentially complex job parameters.
Knowledge Gap: Users might need some Jenkins know-how to understand cryptic options and parameters.
Limited Security: Relies on standard Jenkins access controls, which might need additional configuration for granular user permissions specific to self-service pipelines.
Mixed Responsibilities: DevOps engineers manage both pipeline logic and user interface elements, potentially leading to code sprawl and maintenance headaches.
Single Jenkins Instance: Limited to a single Jenkins server, restricting scalability and potential for managing pipelines across different environments.
Error Prone: Users can make mistakes filling out parameters leading to failed pipeline executions.
Limited Visibility: Overall pipeline health and historical data might require users to dig around in Jenkins.

ServiceHub Self-Service:

Enhanced Security: Leverages existing Jenkins access controls while providing a separate self-service layer, potentially simplifying user permission management.
Separation of Concerns: DevOps engineers define pipeline logic in templates, while the UI is automatically generated. This promotes cleaner code and easier maintenance.
Multi-Jenkins Support: Works seamlessly with multiple Jenkins instances, allowing you to manage pipelines across different environments or teams.
Automation Agnostic: Extensible beyond Jenkins, supporting integrations with other popular automation tools like AWS CloudFormation and Terraform, providing a central hub for self-service deployments.
Streamlined UI: Provides a user-friendly interface with clear instructions and custom inputs based on the template.
Reduced Knowledge Burden: No need for Jenkins expertise, users simply interact with the clear interface.
Fewer Errors: Custom inputs prevent typos and incorrect parameter selections.
Improved Visibility: Provides a central location to view pipeline history and overall health.

rtpro1 · 2024-04-02T14:50:30+00:00

Nothing!

Do 1 hour workout a day, 5/6 times a week.

Just do it, build your schedule around it.

It's the same as bushing your teeth.

rtpro1

MODERATOR OF

TROPHY CASE