Today, we're announcing that we've improved a feature that brings together modern tools, applies those tools to a well-scoped problem for which they are adequately suited, and reduces friction within your team's development lifecycle! It did those things before, but now you can talk to it!

Our CI/CD Review AI feature is now conversational, and ready to be your new interactive assistant for debugging.

What does it do?

The CTO.ai platform was built to reduce friction within your software development lifecycle by helping you shape a Developer Experience that grows with the evolving needs of your team. All of our Review AI features are meant to enhance your Developer Experience, helping you rapidly identify potential issues within your code changes and pipeline failure logs—often before anyone else on your team even notices you requested a review.

With its new conversational abilities, our CI/CD Review AI bot can act as your debugging muse. A rubber duck that talks back, if you will. A chatty… drop of grease to get your gears unstuck?

Stochastic models have failure modes that are impossible to predict or prevent—and the complex cloud environment that underlies your mission-critical infrastructure is the last place you want to introduce additional opportunities for stochastic failure. That’s why we built a CI/CD Review AI!

By applying LLMs in a way that takes advantage of their exceptional ability to extract and present the most salient details from the type of loosely-structured mess of text often encountered in the real world, we’re helping your team reduce the time and effort required to identify problems—all without giving an unpredictable statistical model control over your business-critical data or infrastructure.

How does it work?

As with our other Review AI features, to use our CI/CD Review AI, connect your GitHub account to the CTO.ai platform, then add the CTO.ai Review label to your Pull Request to get started. Adding this label will trigger our Review AI bot to begin its first-pass review of your code changes and to watch for any failed Pipelines runs associated with the Pull Request.

In the event that your Pipeline fails—regardless of whether the cause is a failed test job, an inability to build your container’s image, or some other issue that leads the Pipeline to exit with a non-zero exit code—our CI/CD Review AI rapidly extracts the relevant details from the error logs, then automatically proposes a potential path toward resolution as a review comment, posted directly on the file in question:

These are the potential cause and the proposed solution to the identified problem; that is, they’re suggestions. I have yet to see an example of a response from our Review AI that inaccurately describes the problem, but this is still text being produced by a stochastic model—there is vast potential for failure modes that we are unable to foresee.

The conversational abilities of our Review AI are particularly useful for understanding why seemingly-inaccurate responses may be produced, as off-topic output is often an indicator of subtle errors in a codebase influencing which patterns the model deems the most salient. An LLM can never be confused—apparent errors are merely the model’s transformation of the input failing to conform to the user’s expectations of the output!

Don't get me wrong, as a psycholinguist by training, I love LLMs for exactly what they are: massive computational models which embed the incomprehensibly complex and overlapping statistical relationships that exist within human (and computer) languages. I know I won't find any new ideas in an LLM—only my own input, filtered through a stochastic transformer, and arranged in a quasi-unique way that makes the output feel fresh!

Of course, that’s the fundamental nature of LLMs! Because these models are derived from an unprecedented, mind-bogglingly-huge corpus of publicly-available text, LLMs are, in a sense, a compressed, extremely lossy representation of every idea available on the public-facing internet.

Thus, we are only implementing LLMs in a way that provides guidance for the humans on your team: For a given codebase, the pathways that can lead to a specific error being raised are limited, but there are infinite possibilities for introducing new issues.

If our Review AI provides feedback that is unclear, fails to solve the whole problem, or is simply more complicated than you were expecting, the conversational features make it easy to quickly find clarity!

The most impactful bugs in a codebase can often be some of the smallest. We’ve all been there—a semicolon is missed or parentheses become mismatched or a single variable is swapped for another with a similar name, and the next thing you know, you just lost an hour combing through your code character-by-character to find the culprit—the inevitable consequence of the imperfect perceptions of a squishy human brain.

Context-switching only amplifies the problem, making it even easier for abnormal problems to escape your attention. Fortunately, large language models (LLMs) provide an effective interface for identifying irregularities within structured language, which is just what we need for this sort of problem.

Today, we’re continuing to iterate on our AI roadmap by announcing our new CI/CD Review AI feature! Our goal is to deliver features that reduce friction across your entire development lifecycle, and CI/CD Review AI is designed to help point you in the right direction whenever things go wrong.

What does it provide?

We provide Commands, Pipelines, and Services workflows to build out the foundation of the ideal Developer Experience your team always wished they had. Our Insights and Reports features help you identify opportunities for reducing friction as your workflow evolves. Finally, our other new Review AI features enable rapid iteration, providing you with a first-pass review of your code, and allowing your colleagues to focus on the substance of a Pull Request in their own reviews.

With CI/CD Review AI, our goal is to increase the efficiency of the back half of your Developer Experience by rapidly identifying where to begin your debugging investigation and suggesting some possible paths forward.

How is it used?

Connect your GitHub account to the CTO.ai platform, and add the CTO.ai Review label to a Pull Request—the same label used to trigger our Code Review AI bot!

When the Pipelines triggered by your Pull Request are complete, any that result in a failed Pipeline run will be automatically reviewed by our CI/CD Review AI.

As you can see from the logs in the Pull Request’s Check Runs, the Pipeline run failed as a result of unit test failures in our test Pipeline:

After our CI/CD Review AI processes these logs, the analysis is delivered in the form of a comment on your Pull Request. You can see how the most relevant lines of the Pipeline logs were extracted from the raw output and explained in a neutral way:

Recontextualizing the problem can help break the mental logjams that lead to prolonged debugging sessions. For instance, in this example, the root cause of one test failure is explicitly explained as a “typographical error in the code (or test expectation)”—if you’ve ever spent time sifting through your code for a bug that was actually in your test suite, you’ll appreciate the value of this type of small shift in perspective.

What's next?

We're going to continue iterating on intelligent features that help your team remove friction from your Developer Experience. Stay tuned for more updates!

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

We introduced Code Review AI to make it easier for any team to rapidly iterate and solve problems from day one—developers should be spending their time on building features, not debugging existing code!

To better enhance your Developer Experience, we have made our Review AI conversational.

Now, when our Review AI bot provides your team with feedback, you can ask for clarification and deeper explanations if you're unsure about the feedback you've been presented.

What benefit does this provide?

Our goal is to introduce features that help your team reduce friction throughout your development workflow and improve the overall effectiveness of your software delivery process. The types of errors checked by our Review AI can vary greatly in size, but the long-term impact of any given error in your codebase is often disproportionate to its character count.

In the case of smaller errors (probable typos, using the incorrect variable, etc.), the impact can be significant and difficult to debug, mostly because these types of errors are prone to slipping through the cracks unnoticed. Of course, once a small error is pointed out, it’s usually easy to understand the nature of the mistake and decide how to remedy it.

When our Review AI surfaces larger potential issues inferred from the contents of your code patch—such as concerns about how the code deviates from the recommended best practices for your chosen framework or how inconsistent error handling might cause unexpected crashes—the issues don't always have an obvious path toward resolution.

Regardless of what type of error that our Review AI surfaces for your team, we've made it easier to improve your understanding about the context of the error and how it can be remediated.

How does it work?

After you’ve connected your GitHub account to the CTO.ai platform, you can add the CTO.ai Review label to a Pull Request in one of your repositories to summon our Review AI Bot for a first-pass review of your changes.

But let’s say the bot responds to your patch with potential problems and areas for improvement, but you’re unsure how the advice could actually be applied… What now? Just ask the bot to clarify its response!

Consider, for example, the advice returned by our bot in one case with a recommendation to "use a global promise error handler to manage errors consistently"—it's specific enough to be useful, but not necessarily directly actionable.

With the Conversational Review feature of our Code Review AI, you can now ask the bot for clarification about its recommendations! Below is an example of the type of response the Review AI Bot might provide when asked for clarification:

As you can see in the example above, when asked for clarification about how we should implement a global promise error handler, the bot responds with a mini-tutorial for implementing such a handler in our specific context—in this case, an Express.js app. Included in this response is the code snippet for implementing the error handler and advice for how to integrate this pattern into the rest of the source code.

Watch it in action:

What’s next?

If you’re using our Commands, Pipelines, and Services workflows to orchestrate your cloud application infrastructure, keep an eye on our blog, as we’ll soon be adding features that make it easier to find a path to resolution when things don’t go according to plan at other points in your team’s development lifecycle.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

When teams and organizations work together, one of the critical aspects of working with cloud resources is ensuring that the right people have the right access to the correct resources. This article will explore how to use Google's Identity and Access Management (IAM) and CTO.ai's configs management tool for a secure and efficient onboarding process.

Google Cloud IAM

Google Cloud IAM is a unified credential and access policy management system that offers access controls and visibility for centrally managing cloud resources. With IAM, you can set permissions on specific resources, helping enforce consistent access controls across your environment.

Features of Google Cloud IAM

• Role-Based Access Control (RBAC): Pre-defined roles or custom roles can be assigned to users, groups, or service accounts, giving you flexibility and control.
  
• Policy Inheritance: Policies can be set at the organizational level and then inherited by projects, providing consistency and ease of management.
  
• Audit Logging: You can review who did what, where, and when across Google Cloud in your organization.
  
• Integration with External Identities: IAM can be integrated with external identity providers like Active Directory.

CTO.ai Configs

CTO.ai provides a configuration store for managing non-sensitive data that is required for your automation. The CTO.ai Configuration Management feature complements our Secrets Store (for sensitive information) and enables your team to build a scalable, maintainable, and secure workflow automation system. Combining CTO.ai Configs with IAM, you can create a consistent, secure onboarding process.

Using the Configuration Store can also be a powerful way to chain your automation and enable them to feed input with each other. For example, you can build a workflow that creates a new environment for your engineering team, saving all of the relevant configuration post-creation into the configuration store.

To create Configs on the UI, Click on Settings and select Configs

• Next, add your Config Key and Config Value. Your Config Key can be from your staging, development, or production environments.

• Next, reference the Configs value of your key in your `ops.yml` file in your application directory.
  
• Here is a sample example of how we specified configs in our AWS ECS Fargate ops.yml file

version: "1"
commands:
# setup aws ecs fargate infrastructure
  - name: setup-aws-ecs-fargate:0.3.0
    run: ./node_modules/.bin/ts-node /ops/src/setup.ts
    description: "setup an environment"
    # environment variables 
    env:
    # add static env vars
      static:
        - STACK_TYPE=aws-ecs-fargate
        - AWS_REGION=us-west-1
        - JSII_DEPRECATED=quiet
      # add and store aws secrets
      secrets:
        - AWS_ACCESS_KEY_ID
        - AWS_SECRET_ACCESS_KEY
        - AWS_ACCOUNT_NUMBER
      # pass environment host and database configurations
      configs:
        - DEV_AWS_ECS_FARGATE_STATE
        - STG_AWS_ECS_FARGATE_STATE
        - PRD_AWS_ECS_FARGATE_STATE
        - DEV_AWS_ECS_FARGATE_CLUSTER_VAULT_ARN
        - STG_AWS_ECS_FARGATE_CLUSTER_VAULT_ARN
        - PRD_AWS_ECS_FARGATE_CLUSTER_VAULT_ARN
        - DEV_AWS_ECS_FARGATE_SERVICE_VAULT_ARN
        - STG_AWS_ECS_FARGATE_SERVICE_VAULT_ARN
        - PRD_AWS_ECS_FARGATE_SERVICE_VAULT_ARN
  # deploy environment on aws ecs fargate workflow
  - name: deploy-aws-ecs-fargate:0.3.0
    run: ./node_modules/.bin/ts-node /ops/src/deploy.ts
    description: "deploy to an environment"
    env:
    # add static env vars
      static:
        - STACK_TYPE=aws-ecs-fargate
        - AWS_REGION=us-west-1
        - JSII_DEPRECATED=quiet
    # add and store aws secrets
      secrets:
        - AWS_ACCESS_KEY_ID
        - AWS_SECRET_ACCESS_KEY
        - AWS_ACCOUNT_NUMBER
    # pass environment host, resource, and database connections
      configs:
        - DEV_AWS_ECS_FARGATE_STATE
        - STG_AWS_ECS_FARGATE_STATE
        - PRD_AWS_ECS_FARGATE_STATE
        - DEV_AWS_ECS_FARGATE_CLUSTER_VAULT_ARN
        - STG_AWS_ECS_FARGATE_CLUSTER_VAULT_ARN
        - PRD_AWS_ECS_FARGATE_CLUSTER_VAULT_ARN
        - DEV_AWS_ECS_FARGATE_SERVICE_VAULT_ARN
        - STG_AWS_ECS_FARGATE_SERVICE_VAULT_ARN
        - PRD_AWS_ECS_FARGATE_SERVICE_VAULT_ARN
    # destroy aws ecs fargate infrastructure 
  - name: destroy-aws-ecs-fargate:0.1.0
    run: ./node_modules/.bin/ts-node /ops/src/destroy.ts
    description: "destroy an environment"
    env:
    # add static env vars
      static:
        - STACK_TYPE=aws-ecs-fargate
        - AWS_REGION=us-west-1
    # add and store aws secrets
      secrets:
        - AWS_ACCESS_KEY_ID
        - AWS_SECRET_ACCESS_KEY
        - AWS_ACCOUNT_NUMBER
    help:
      usage: ops run vault <sub-cmd> <--key> <--value>
      arguments: 
        init: 'init the environments vault'
        set: 'set a key in the enviroment vault'
        ls: 'list keys in the environment vault'
        rm: ' remove a specific key in the environment vault'
        destroy: 'destroy the environment vault'

Features of CTO.ai Configs

• Automated Workflows: You can set up automation to streamline onboarding, ensuring every new user has the appropriate access and configurations.
  
• Enforce Security Policies: By using configurations, you can set up required security measures for each role or user, making sure that every onboarded member meets the security guidelines.

Conclusion

By using Google Cloud's IAM for role-based access control and CTO.ai's configuration management for standardization and automation, organizations can create a robust, efficient, and secure onboarding process. Regular monitoring and auditing further ensure that the system remains compliant and resilient to potential threats.

CTO.ai Configs not only enhances security but also facilitates the efficient onboarding of new team members, allowing organizations to scale and adapt quickly in an ever-changing technological environment.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

Virtual Private Clouds (VPCs) provide a secure environment for your resources, isolating them from public access while facilitating inter-resource communication. Managing VPCs effectively is pivotal for ensuring the security, performance, and flexibility of your deployments. Today, we'll dive into how CTO.ai enables straightforward VPC network configuration management through its deployment tooling.

Prerequisites

• GCP account
• A created project on GCP
• Docker installed on your local machine
• A CTO.ai account
• CTO.ai GCP workflow is installed on your machine, and Ops CLI installed.
• Pulumi Token installed on your project
  

Configure and Set up GCP Workflows

Before we get started with this guide, install the GCP GKE Pulumi Py workflow.

If you don't have access to the repository, kindly contact us at support@cto.ai

The repo includes a complete IaC for deploying infrastructure over GCP: Kubernetes, Container Registry, Database Clusters, Load Balancers, and Project Resource Management, all built using Python + Pulumi + CTO.ai.

Clone the repository with:

git clone “https://github.com/workflows-sh/gcp-gke-pulumi-py.git” 

cd gcp-gke-pulumi-py

Run and Set up your Infrastructure

Next, you need to build and set up the infrastructure that will deploy each resource to GCP using the GCP workflow stack. Set up your infrastructure using the ops run -b . This will provision your stack and set up your infrastructure.

• Select setup infrastructure over GCP
• This process will build your Docker image and start provisioning your GCP infra resources.
• Next, select the services you want to deploy from the CLI. We will select the “all” service and install all the dependencies, which will also provision our GCP container registry.
• Back in the GCP console, click on your container registry, and you will see your Container Registry created for usage.
  
• When your resources are deployed and your infra is created, you can view your VM instances, Database, GKE, and other resources you will use in your GCP console.
• We can now see our machine configuration.
  
• Back in your GCP console, you can also see your GKE cluster.
  
• When you click on it, you can see the Machine configuration and Network config

What is CTO.ai?

Before we delve into the depths of VPC management, it's crucial to understand CTO.ai. CTO.ai is a platform that allows developers to create, share, and run cloud-native workflows efficiently. By leveraging this platform, you can streamline processes, reduce overhead, and ensure consistency across your deployments.

VPC Network Configurations with CTO.ai

You can manage and work with the GCP module provided in the CTO.ai workflow here The code snipper offers a glimpse into how VPC configurations can be managed using the `pulumi_gcp` module, which interfaces with the Google Cloud Platform.

Class Initialization

class VpcNetwork:
outputs = dict()
def __init__(
self, id="", name="default", description="", auto_create_subnetworks=True
):

This code initializes a VpcNetwork class that will represent our VPC. The constructor takes in several parameters:

• Id: A unique identifier for the VPC
• Name: The name of the VPC, defaulting to default
• Description: A description of the VPC’s purpose of characteristics
• Auto_create_subnetworks: A flag determining whether subnetworks within the VPC should be created automatically.
  

Creating the VPC Network

vpc_network = gcp.compute.Network(
self.id,
name=self.name,
description=self.description,
auto_create_subnetworks=self.auto_create_subnetworks,
)

This segment utilizes the pulumi_gcp module to create a VPC network in GCP. The properties provided to the Network constructor are fetched from the initialized class attributes.

Storing Important Outputs

self.outputs["self_link"] = vpc_network.self_link
self.outputs["vpc_id"] = vpc_network.id

After the VPC network is created, essential information like its self_link and id is stored in the outputs dictionary for further reference or use.

Why Use CTO.ai for VPC Network Configurations?

• Automated Deployments: Using CTO.ai enables automated VPC deployments, ensuring that your networks are consistently and reliably set up.
  
• Version Control: As with any code-based approach, you can leverage version control tools like Git to manage your VPC configurations. This way, you have an audit trail of changes, can roll back if necessary, and collaborate seamlessly with your team.
  
• Enhanced Security: Through CTO.ai, you can ensure that VPCs are set up following best practices, minimizing the risk of misconfigurations that could expose your resources.
  
• Scalability: As your infrastructure grows, having an automated, code-driven method to manage VPCs allows you to scale seamlessly.

Closing Thoughts

VPCs play a foundational role in cloud architectures. They define the boundaries within which our resources operate, determining their accessibility and interaction patterns. Managing VPCs effectively ensures optimized performance and robust security. With CTO.ai and pulumi_gcp, you're equipped with powerful tools to manage VPCs efficiently, securely, and consistently.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

In today’s agile development landscape, continuous integration and continuous deployment (CI/CD) have become fundamental practices for modern software deployments. CTO.ai stands as one of the industry leaders in this arena, offering seamless integration and deployment pipelines. Integrating CTO.ai with AWS CloudWatch for alerting can enhance your pipeline by notifying you about the build status and any anomalies that may occur during the build process.

In this blog post, we will walk you through the process of setting up AWS CloudWatch alerts for CTO.ai builds step by step.

Prerequisites

Before we begin, ensure that you have the following:

• An AWS account is set up and configured with the necessary access rights.
• A CTO.ai account.
• AWS CLI was installed and configured with the necessary access credentials for your AWS account.

Setting Up AWS CloudWatch

The first step involves setting up AWS CloudWatch in your AWS console. Go to the AWS CloudWatch service and create a new dashboard. In the AWS dashboard,  you can configure various metrics and alarms.

Setting Up an IAM Role for CTO.ai Workflows

To allow CTO.ai to send data to CloudWatch, create an IAM role with the necessary permissions. Grant permissions like cloudwatch:PutMetricData to allow CTO.ai to push metrics to CloudWatch.

Configuring CTO.ai Environment

Next, configure your CTO.ai environment variables to include AWS access credentials. You would typically do this in the project settings under secrets. When you are done, you can deploy any of our AWS Workflow stacks that suit your needs. We currently have the AWS ECS fargate workflow and the AWS EKS ASG workflow. Once you have deployed your infrastructure, create a Dockerfile and ops.yml file in your project repository, using our public sample repository as guidance for defining your own application and services.

Integrating CTO.ai and AWS CloudWatch

In your ops.yml file, replace the event values with your own values and define your jobs. Be sure to specify the Docker, AWS, and bash commands and workflow commands necessary to build and deploy your application container image.

version: "1"
pipelines:
  - name: sample-expressjs-pipeline-aws-ecs-fargate:0.1.1
    description: build a release for deployment
    env:
      static:
        - DEBIAN_FRONTEND=noninteractive
        - ORG=workflows-sh
        - REPO=sample-expressjs-aws-ecs-fargate
        - AWS_REGION=us-west-1
        - STACK_TYPE=aws-ecs-fargate
      secrets:
        - GITHUB_TOKEN
        - AWS_ACCESS_KEY_ID
        - AWS_SECRET_ACCESS_KEY
        - AWS_ACCOUNT_NUMBER
    events:
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.merged"
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.opened"
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.synchronize"
    jobs:
      - name: sample-expressjs-build-job-aws-ecs-fargate
        description: sample-expressjs build step
        packages:
          - git
          - unzip
          - python
        steps:
          - curl https://s3.amazonaws.com/aws-cli/awscli-bundle-1.18.200.zip -o awscli-bundle.zip
          - unzip awscli-bundle.zip && ./awscli-bundle/install -b ~/bin/aws
          - export PATH=~/bin:$PATH
          - aws --version
          - git clone https://$GITHUB_TOKEN:x-oauth-basic@github.com/$ORG/$REPO
          - cd $REPO && ls -asl
          - git fetch && git checkout $REF
          - aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_NUMBER.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO
          - docker build -f Dockerfile -t $AWS_ACCOUNT_NUMBER.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO-$STACK_TYPE:$REF .
          - docker push $AWS_ACCOUNT_NUMBER.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO-$STACK_TYPE:$REF
          # Adding CloudWatch metric and alarm commands
          - aws cloudwatch put-metric-data --metric-name BuildSuccess --namespace "CTO.ai" --value 1
          - aws cloudwatch put-metric-alarm --alarm-name build_failure_alarm --alarm-description "Alarm for build failures" --metric-name BuildFailure --namespace "CTO.ai" --statistic SampleCount --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --dimensions Name=Build,Value=Failed --evaluation-periods 1 --alarm-actions arn:aws:sns:us-west-1:$AWS_ACCOUNT_NUMBER:MyTopic
services:
  - name: sample-expressjs-service-aws-ecs-fargate:0.1.1
    description: A sample expressjs service
    run: node /ops/index.js
    port: [ '8080:8080' ]
    sdk: off
    domain: ""
    env:
      static:
        - PORT=8080
    events:
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.merged"
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.opened"
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.synchronize"
    trigger:
     - build
     - publish
     - start

Creating CloudWatch Alarms

Next, create CloudWatch Alarms to receive notifications. Navigate to the CloudWatch dashboard, create a new alarm, and define the conditions based on the CTO.ai metrics you have set up. Add the dashboard widget you want for your logs and metrics tooling.

Configuring Notification

Configure a notification to get alerted when the alarm state is triggered. AWS SNS (Simple Notification Service) can be used to set up email or SMS notifications.

Testing Your Setup

Finally, test your setup by triggering a build in CTO.ai using the ops build . You can also trigger your workflows when the event triggers you configured are met. Once the build completes, it should send the metrics to CloudWatch, and if the conditions are met, the alarm will trigger, sending a notification through the SNS topic you configured.

Conclusion

Setting up AWS CloudWatch alerts for CTO.ai can be a potent combination, ensuring that you are promptly notified of any issues in your CI/CD pipeline, thus maintaining a robust and reliable deployment process. By following the above steps, you can set up a monitoring and alerting system that will aid in proactive issue detection and resolution, bringing efficiency and stability to your deployment pipeline. Happy coding!

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

Container orchestration has become a useful technique for deploying, scaling, and managing containerized applications. However, efficiently directing traffic into these containers remains a challenge. This blog post delves into container-native load balancing using Ingress, a powerful tool for routing traffic to services within a Kubernetes cluster. We'll explore the concept, benefits, and how to implement it, complete with code configuration examples.

Understanding Container-Native Load Balancing

Traditional load balancers operate at the infrastructure level, unaware of the application's specific needs. Container-native load balancing, on the other hand, allows the load balancer to communicate directly with the containers, enabling more intelligent traffic distribution. This approach ensures high availability, scalability, and optimal resource utilization, which is critical for microservices architectures.

Why Ingress?

Ingress, in the Kubernetes ecosystem, is an object that allows access to your Kubernetes services from outside the Kubernetes cluster. You configure HTTP and HTTPS routes to services based on request parameters like paths or hostnames. But why is it significant?

• Path-Based Routing: With Ingress, you can route traffic to different services based on URL paths. This makes it easy to host multiple services under the same IP address.
  
• Simplified Management: Ingress allows you to manage all your routes centrally, simplifying configuration and management.
  
• Enhanced Security: Using Ingress, you can provide secure access through SSL/TLS termination, protecting your data in transit.

Prerequisites for Using Ingress Before you implement Ingress, ensure you have the following:

• A Kubernetes cluster is up and running.
• An Ingress controller is installed in the cluster (e.g., NGINX, Traefik, AWS Load Balancer Controller).
• The kubectl command-line tool is connected to your cluster.

Deploy Your Application

First, deploy the applications that you want to expose via Ingress. Here’s an example deployment configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-application
spec:
  selector:
    matchLabels:
      app: my-application
  replicas: 3
  template:
    metadata:
      labels:
        app: my-application
    spec:
      containers:
      - name: my-application
        image: my-image
        ports:
        - containerPort: 8080

Apply this configuration with kubectl apply -f <filename>.yaml

Create a Service

Each deployment should have a corresponding service to expose it internally within the cluster.

apiVersion: v1
kind: Service
metadata:
  name: my-application-service
spec:
  selector:
    app: my-application
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Configure the Ingress Resource

• Now, define your Ingress resource. This resource will use the Ingress controller to manage access to services, based on the rules defined.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-fanout-example
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: my-application.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-application-service
            port:
              number: 80

Here, we define a rule that all traffic requesting the my-application.com domain should be routed to the my-application-service.

Advanced Ingress Features

• SSL/TLS Termination: Secure your Ingress by adding SSL/TLS termination.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-example-ingress
spec:
  tls:
  - hosts:
      - sslexample.foo.com
    secretName: testsecret-tls
  rules:
      - host: sslexample.foo.com
        http:
          paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

This configuration specifies a secret that contains TLS certificate and key for the specified domain.

Conclusion

Container-native load balancing through Ingress not only simplifies traffic management in microservices environments but also ensures optimal resource utilization and high availability. By using CTO.ai Kubernetes Ingress resources and an Ingress controller, organizations can efficiently route traffic, implement advanced routing policies, and expose services to the outside world securely and efficiently.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

Code Review AI from CTO.ai is a new feature helping every development team rapidly get the feedback they need to stop small problems from snowballing into large ones—even teams that have yet to configure an effective test harness for their development process.

When it comes to elevating the quality of code produced by your entire team, one of the most important factors driving this improvement is the overall cadence of your code review cycle. Quicker reviews for new code lead to quicker development cycles, helping improve the quality of your code—which drives a faster lead time for change, a higher deployment frequency, and improved deployment reliability.

Code Review AI helps by checking your code for the types of errors that are most easily introduced into a codebase, freeing the rest of your team to focus their efforts on a higher-level analysis of the impact of the changes made to your code.

Of course, we're focused on building features that deliver immediate value to our users, and this is just the beginning of our AI roadmap. Our AI features are in an alpha stage for now, and we want your feedback on how AI can help you improve your developer experience! If you're interested in applying AI technologies to enhance your Developer Experience, we'd love to hear from you and discuss how we can help remove friction from your development workflow.

Code reviews are an often-overlooked aspect of software development within a smaller team/company. That is why CTO.ai’s new Code Review AI feature is so valuable. It can quickly provide that syntax-level linting and code logic review to help root out any overlooked issues that can quickly derail a deployment; all so I can focus on the larger features’ viability and polish during my review. Since each review’s scope is limited to that of the pull-request, I know that my code is both private and secure. In my opinion, this is a great use of the ever-growing artificial intelligence and large-language model technology to both support and improve my team’s code quality.

Doug Niccum
Software Engineering Manager, Schier

Why

Your Developer Experience shapes how your team collaborates within its entire development lifecycle, and small improvements to DX can have a huge impact on your team’s effectiveness in the long run. To support the flexibility required for constructing your ideal Developer Experience—whatever that may look like!—we began with the primitives that form the basis of your workflow: Commands, Pipelines, and Services.

As we’ve built out our Developer Control Plane (DCP), our goal has been to help you build the Developer Experience (DX) that your team always wished it had, then help you measure its effectiveness—not to assess the productivity of individual developers, but to understand where friction enters your development process. That’s where Insights and Reports come in: these measures of software delivery effectiveness help you understand how your performance changes as your development lifecycle evolves.

Now, we're adding intelligent features to augment and accelerate your workflow! And just like our other features, you only need to use the ones that actually enhance your workflow—anyone can make use of Code Review AI on its own, without needing to build and measure their infrastructure through the CTO.ai platform.

How

Anyone is welcome to try out our Code Review AI feature today through our GitHub integration. After connecting your GitHub account to CTO.ai, you’re ready to test it.

Begin by creating a new Pull Request in a repo associated with the GitHub account or organization that was linked to CTO.ai. Then, you’ll need to create the appropriate label in the GitHub repository where your Pull Request was created; this label should have the text CTO.ai Review.

Finally, add the newly-created CTO.ai Review label to trigger the Code Review AI Bot to review the pull request:

Now, each change added to the Pull Request will be reviewed for errors by the Code Review AI Bot! You can see below how minor mistakes—with the potential to cause larger problems at a later point in time—are caught by the automated review. Most notably, they are the types of errors that are easy to make and even easier to overlook:

Let’s break down this response: For each diff in your Pull Request, the CTO.ai Bot will post a comment analyzing its content.

• (A) For each diff in your Pull Request, the CTO.ai Bot will post a comment analyzing its content.
• (B) A potential issue with inconsistent property names is raised; in this case, when the name used to access the property was changed, it wasn’t updated in all places.
• (C) A potential issue with the logic of the application code is raised, pointing out a condition that could cause a request to hang indefinitely.
• (D) The review points out that a certain function doesn’t exist, and correctly identifies which function was likely meant to be called at this line!
• (E) Debugging code that makes its way into a production environment is always a problem, and in this case, the review bot identified when the code seemed to be run with a fixed set of parameters.
• (F) A lack of input validation is also highlighted, as it has the potential to produce surprising results when that code is executed.
• (G) Finally, all of the potential problems are summarized in a way that provides further guidance for resolving the errors.

It’s as simple as that. This automation feature isn’t meant to replace peer-review of code changes, provide you with advice about application architecture, or actively help you write code!

Instead, Code Review AI helps every development team quickly get actionable first-pass feedback that can be used to fix subtle problems before they ever make it to production—even when a team isn’t able to configure linting and test harnesses as part of their development workflow from day one.

What's coming next?

This is just the starting line for our roadmap. We don't want to tack on useless, gimmicky features-- just tools that can help your team augment and streamline your Developer Experience.

Down the road, we want to help you train and deploy private models that meet your needs and keep your data in your own hands. If your team is interested in leveraging these LLMs with your own data, our platform can help you. We can help you harness your data to train your own models that provide a more contextual and in-depth review process.

We believe AI tooling should support and enhance your development lifecycle, and our primary goal is always to help you remove friction from your Developer Experience. But general-purpose tooling can only get you so far!

And if you don't want to send any of your code to a third-party company, we get it—let's discuss how we can help you deploy your own models to enhance your team’s Developer Experience. For the specific needs of your team, we'll work with you to implement a fine-tuned model that keeps your data in your own hands.

Prometheus, an open-source system monitoring and alerting toolkit, can be a cornerstone in setting up a robust alerting mechanism to facilitate this. In this blog, we will delve deep into creating custom alerting solutions using Prometheus and CTO.ai, ensuring that you have an efficient alert system that notifies you of potential issues before they escalate into more serious problems.

Prerequisites

Before we dive into this blog, ensure you have the following setups:

• CTO.ai account
• Helm installed in your K8s cluster
• Prometheus and Grafana are installed in your K8s cluster
• Kubernetes Cluster: A functioning Kubernetes cluster, set up and configured with kubectl.
• Helm: Helm package manager installed in your system.

Setting up CTO.ai EKS Workflow

Start by connecting your GitHub account and installing the EKS EC2 ASG workflow we support,  and choose the repository where your Kubernetes configurations are stored.

git clone git@github.com:workflows-sh/aws-eks-ec2-asg-cdk.git

cd aws-eks-ec2-asg-cdk

Next, set up and add your secret keys, AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_ACCOUNT_NUMBER, and GITHUB_TOKEN with write permissions to the project secret settings in CTO.ai.

After cloning the repo from GitHub, run and build your Workflow using ops build -b . and deploy your infrastructure to AWS.

• Enter the name of your environment. You can use dev as the name of your environment. You can also use Prod or Stage, depending on what you want.
• Your workflow will start deploying and creating your resources on AWS using CloudFormation
• After deploying your AWS EC2 and Elastic Kubernetes workflow, you can see your stack directly on AWS CloudFormation. In your CloudFormation Stack, you can see your AWS resources created: Dev-AWS-EKS-ASG-Provider, AWS-EKS-EC2-ASG Resource, Dev-AWS-EKS-EC2-ASG, Sample-App-AWS-EKS, CDKToolkit, Dev-Sample-App-AWS-EKS-EC2-ASG.

Installing Prometheus Operator

Installing the Prometheus Operator using Helm is a straightforward and manageable method. Begin by adding the Prometheus community Helm chart:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts


helm repo update

Next, create a values.yaml file to hold your custom configurations and install the Prometheus Operator:

helm install prometheus prometheus-community/prometheus

• Back in your terminal, you can view your Prometheus pods using the kubectl get pods command.
• Prometheus is now accessible for your workloads. Next, get your service using kubectl get svc so you can access your Prometheus server from your localhost web UI.
• Port-Forward into your service using kubectl port-forward service/prometheus-server 9090:80

Building Custom Alerting Solutions with Prometheus

In Prometheus, alerting rules are defined in the Prometheus configuration file (a YAML file). The alerting rules are defined based on the Prometheus expression language expressions.

• To create an alerting rule, you need to define the alert conditions and the actions to be taken when the alert conditions are met. You can use PromQL to define the conditions that will trigger the alert. For instance, you can create a rule to alert when the average CPU usage goes beyond 75% for a period of 5 minutes:

groups:
- name: example
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100) > 75
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "High CPU usage"
      description: "CPU usage is above 75% for more than 5 minutes"

• You can also view the status of your resources like rules, targets, service discovery, TSDB status, runtime, and build information.
• Alert Manager handles the alerts sent by Prometheus server and takes care of grouping, inhibition, and sending out notifications through various channels. Set up routes and receivers in Alertmanager to manage alerts efficiently:

route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'web.hook'
receivers:
- name: 'web.hook'
  webhook_configs:
  - url: 'http://webhook.url'

Conclusion

Crafting custom alerting solutions with Prometheus and CTO.ai is a strategic approach in safeguarding your production environments. It not only allows you to detect and address issues promptly but also grants you the flexibility to tailor your alerting solution to meet your specific needs, creating a more resilient and responsive monitoring system.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

As software delivery becomes more sophisticated, Continuous Integration/Continuous Deployment (CI/CD) practices are essential to maintain a consistent and efficient development lifecycle. One platform facilitating this process is CTO.ai, a CI/CD tool enabling developers to automate their workflows and enhance productivity.

As we increase software deployments via automation, there's an associated risk of vulnerabilities and breaches. Thus, it's imperative to secure your CI/CD pipeline. This article aims to provide key steps to enhance security when using CTO.ai in your CI/CD pipeline.

CTO.ai Security Features

CTO.ai offers several built-in features that can assist you in securing your CI/CD pipelines:

Pipeline Activity Logs

CI/CD pipeline activity logs, also known as audit logs or event logs, are records of all events and activities that happen within a CTO.ai CI/CD pipeline.

When a CI/CD tool like CTO.ai executes the various stages of the pipeline, such as build, test, and deploy, it generates a log of each action. These logs can include information like who triggered the pipeline, what changes were made, when the changes occurred, which jobs were run, and the outcome of each job.

These activity logs serve several purposes:

• Troubleshooting: Logs can be invaluable in diagnosing and debugging when things go wrong in a CI/CD pipeline. They can help identify which step failed and why.
  
• Auditing: They provide a trail of actions for auditing purposes. Organizations can review logs to ensure compliance with internal policies or external regulations.
  
• Security: Logs can also be used for security monitoring. Unusual patterns in activity logs can indicate potential security issues, such as unauthorized access or attempts to alter the pipeline maliciously.
  
  Activity logs can be obtained from your CI/CD pipeline, and they record every action within your pipeline. This helps monitor your pipeline's activity, making it easier to detect and address potential security threats.

Secrets Management

CTO.ai provides a secure method to store, manage, and use sensitive data (like API keys or credentials and database endpoints) within your CI/CD pipeline.

What are Secrets and Configs?

Secrets are sensitive data such as passwords, API keys, or credentials that should not be exposed in your codebase or version control system. Configs, on the other hand, are tuneable parameters of your application that can vary across different environments.

CTO.ai Secrets and Configs Management

CTO.ai provides a robust mechanism to manage secrets and configurations securely within your CI/CD pipeline:

1. Secure Storage: CTO.ai allows you to store secrets securely, keeping them out of your codebase. This prevents secrets from being exposed in log outputs or version control systems.
   
2. Environment Configurations: With CTO.ai, you can maintain different sets of configurations for different environments, such as development, testing, and production. This enables a clear separation of concerns and reduces the risk of misconfigurations that could lead to security vulnerabilities.

version: "1"
commands:
# setup aws ecs fargate infrastructure
  - name: setup-aws-ecs-fargate:0.3.0
    run: ./node_modules/.bin/ts-node /ops/src/setup.ts
    description: "setup an environment"
    # environment variables 
    env:
    # add static env vars
      static:
        - STACK_TYPE=aws-ecs-fargate
        - AWS_REGION=us-west-1
        - JSII_DEPRECATED=quiet
      # add and store aws secrets
      secrets:
        - AWS_ACCESS_KEY_ID
        - AWS_SECRET_ACCESS_KEY
        - AWS_ACCOUNT_NUMBER
      # pass environment host and database configurations
      configs:
        - DEV_AWS_ECS_FARGATE_STATE
        - STG_AWS_ECS_FARGATE_STATE
        - PRD_AWS_ECS_FARGATE_STATE

Above is a sample configuration of using Configs and Secrets in CTO.ai.

Securing Your Pipeline with CTO.ai Secrets and Configs

Below are some best practices for managing secrets and configurations in your CI/CD pipeline using CTO.ai:

Store Secrets Securely

Use CTO.ai's secrets management feature to store all sensitive information. This keeps these secrets out of your codebase and prevents them from being inadvertently exposed.

Never Hardcode Secrets

Never hardcode secrets in your application code or configuration files. Hardcoded secrets can easily be exposed or leaked, leading to serious security risks.

Use Environment-Specific Configurations

Use different sets of configurations for different environments. This ensures that testing or development configurations (which might be less secure) do not accidentally get deployed into your production environment.

Keep Secrets and Configs Updated

Regularly update your secrets and configurations, particularly if you suspect a breach. Regular updates help ensure the security of your pipeline.

Limit Access to Secrets and Configurations

Only grant access to secrets and configurations to those who need it. Following the principle of least privilege can significantly enhance the security of your CI/CD pipeline.

In conclusion, managing secrets and configurations correctly is a key part of securing your CI/CD pipeline. By using CTO.ai's robust secrets and configurations management features, you can ensure the security of your pipeline while still enjoying the benefits of CI/CD automation. Remember, security is not a one-off task but a continuous process that should always be part of your development workflow.

Unlock the Power of Secure CI/CD Pipelines with CTO.ai

As you embark on your DevOps journey, don't leave security behind. Embrace the secure CI/CD pipelines with CTO.ai and experience the transformative power of secure automation. Discover how CTO.ai can fortify your workflows and provide the security your development process needs. Don't wait – explore CTO.ai today and lead your team to a safer, faster, and more efficient software delivery process.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

Businesses need to ensure not only the consistency and reliability of their applications but also the ability to scale resources up or down based on demand. Traditionally, Virtual Machines (VMs) have been the go-to solution for isolating and running applications in self-contained environments. However, as the scale and complexity of applications grow, managing many Virtual Machines (VMs) becomes quite challenging. This is where Kubernetes enters the scene, offering a better and more automated approach to orchestration and scaling.

In this article, we’ll learn the advantages of Kubernetes over Virtual Machines (VMs), and also touch upon how CTO.ai uses Kubernetes to offer seamless scalability and continuous integration.

Efficient Resource Utilization

Kubernetes orchestrates containers – a lighter-weight alternative to VMs. Unlike VMs, containers share the host system’s OS kernel, thus consuming less resources and booting up significantly faster. This leads to better resource utilization and cost-efficiency.

Automated Scheduling and Self-healing

Kubernetes boasts automated scheduling and self-healing capabilities. It intelligently schedules containers based on resource availability and can automatically replace, reschedule, and restart containers that fail, ensuring high availability and reliability.

Enhanced Scaling and Load Balancing

With Kubernetes, scaling is almost instantaneous, either manually or through autoscaling based on CPU usage or other selected metrics. Load balancing is inherent, distributing network traffic efficiently across multiple containers to ensure no single point of failure.

Declarative Configuration and Versioning

Kubernetes allows for declarative configuration, enabling developers to describe the desired state of the system, which Kubernetes then ensures. Versioning and rollback are also simplified, making updates and rollbacks straightforward.

Ecosystem and Community

Kubernetes has a rich ecosystem with a lot of tools and a vibrant community. This ecosystem facilitates easy integration with various tools like CTO.ai for Continuous Integration/Continuous Deployment (CI/CD) processes.

Integrating CTO.ai for Enhanced Scalability and Continuous Integration

CTO.ai, a modern continuous integration and continuous deployment platform, aligns well with Kubernetes’ scalability and orchestration benefits. With Kubernetes, CTO.ai provides a robust platform (Developer Control Plane) that automatically scales build environments, ensuring that CI/CD pipelines run efficiently even as the complexity and number of projects grow.

CTO.ai employs Kubernetes to orchestrate the execution of build jobs in scalable, isolated environments. This integration allows for enhanced resource management, enabling developers to focus more on coding and less on infrastructure management.

Moreover, CTO.ai’s Kubernetes integration facilitates a very quick transition from development to production, ensuring that applications are reliably delivered at scale, meeting the demands of modern software development cycles.

Get Started with CTO.ai and Kubernetes

In conclusion, the relationship between Kubernetes and CTO.ai showcases a modern approach to managing and scaling applications. With Kubernetes simplifying the orchestration and scaling aspects and CTO.ai ensuring efficient and reliable CI/CD processes, organizations are well-poised to meet the ever-evolving demands of the tech landscape.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

The software development world has witnessed a paradigm shift with the advent of container technology, pioneered by Docker in 2013. Containers encapsulate an application and its dependencies into a single, isolated unit, ensuring consistent, reliable, and rapid deployment across various computing environments. Migrating to containers brings many benefits, including resource efficiency, scalability, and portability. Let's dive into the detailed advantages of adopting containers.

Resource Efficiency

• Less Overhead: Unlike virtual machines (VMs), containers share the host system’s OS kernel, removing the need for a full OS stack for each instance, thus reducing overhead.
  
• Optimized Utilization: Containers enable higher resource utilization by allowing multiple containerized applications to share the same host, improving hardware efficiency.
  
• Dynamic Allocation: Containers facilitate dynamic resource allocation, ensuring optimal performance by utilizing resources as per the application needs.

Scalability, Performance, and CTO.ai

• Microservices and Rapid Scaling: Containers support microservices architecture, allowing rapid scaling. CTO.ai enhances this by facilitating automated scaling in response to workload changes.
  
• Performance Optimization: CTO.ai helps optimize container performance through customizable resource classes, ensuring applications run efficiently.

Portability, Consistency, and Multi-Cloud Compatibility

• Environment Consistency: Containers, with their encapsulated dependencies, ensure consistent environments. CTO.ai reinforces this by providing a consistent CI/CD pipeline across multiple platforms.
  
• CTO.ai Jobs: With CTO.ai Jobs and Configs, reusable configuration elements, developers can seamlessly deploy containerized applications across different cloud providers, promoting multi-cloud strategies.

Development Lifecycle Improvements

• DevOps Friendly: Containerization aligns well with DevOps practices by promoting continuous integration/continuous deployment (CI/CD) through automation and configuration management.
  
• Rapid Deployment: With containers, applications can be deployed quickly and efficiently, reducing time-to-market.
  
• Rollbacks and Versioning: Containers support easy versioning and rollbacks, enabling developers to revert to previous application states effortlessly.

Isolation and Security

• Process Isolation: Each container runs in isolation, ensuring that the failure or compromise of one does not directly affect others.
  
• Immutable Infrastructure: Containers advocate for immutable infrastructure, where infrastructure changes are made by deploying new containers, reducing inconsistencies and security risks.
  
• Security Scanning: Container images can be scanned for vulnerabilities during the development cycle, ensuring a secure deployment.

Cost Reduction

• Reduced Infrastructure Costs: Improved resource utilization and efficiency lead to reduced infrastructure requirements and costs.
  
• Maintenance and Licensing: With fewer OS instances than VMs, containers can significantly reduce maintenance efforts and licensing costs.
  
• Operational Efficiency: Automation and improved deployment practices result in operational efficiencies and cost savings.

Conclusion

Migrating to containers, complemented by the capabilities of CTO.ai, offers a strategic advantage for organizations aiming for agility, efficiency, and scalability. The combination of containerization and CTO.ai’s continuous integration and deployment features forms a powerful synergy, enabling businesses to realize the full potential of modern application development and deployment. While the benefits are numerous, it is essential for organizations to tailor their migration strategy according to their specific needs and objectives.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

AWS CloudWatch provides robust monitoring solutions that enable you to track and analyze logs efficiently with CTO.ai. In this blog, we'll follow a step-by-step guide on configuring CloudWatch Logs for AWS ECR using CTO.ai workflows.

Prerequisites

• A functioning AWS account with appropriate permissions and IAM roles for AWS ECR.
• An AWS ECR repository.
• CTO.ai account and a project set up with repository access installed with the AWS Workflows

Set Up AWS Identity and Access Management (IAM) Roles and Policies

Before we begin, we need to ensure that the IAM role associated with your CTO.ai workflow has the necessary permissions to send logs to CloudWatch.

• Create a Policy with permissions to write logs to CloudWatch. Save it as CloudWatchLogsPolicy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*",
      "Effect": "Allow"
    }
  ]
}

• Attach the Policy to the IAM role used by your application stack.

Set up and Configure your CTO.ai Ops.yml file

Next, we’ll create and configure our ops.yml file for our ECR project. This file will be located in the directory where your ECR project is. In your CTO.ai project settings, add your AWS credentials (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) as environment variables.

Creating a CTO.ai Workflow to Push Images to ECR

Here, we are setting up a CTO.ai job that triggers every time there is a push to your repository, and it pushes logs to AWS CloudWatch. To integrate this setup with AWS ECR, include steps in your workflow to build and push Docker images to your ECR repository.

version: "1"
pipelines:
  - name: sample-expressjs-pipeline-aws-ecs-fargate:0.1.1
    description: build a release for deployment
    env:
      static:
        - DEBIAN_FRONTEND=noninteractive
        - ORG=workflows-sh
        - REPO=sample-expressjs-aws-ecs-fargate
        - AWS_REGION=us-west-1
        - STACK_TYPE=aws-ecs-fargate
      secrets:
        - GITHUB_TOKEN
        - AWS_ACCESS_KEY_ID
        - AWS_SECRET_ACCESS_KEY
        - AWS_ACCOUNT_NUMBER
    events:
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.merged"
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.opened"
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.synchronize"
    jobs:
      - name: sample-expressjs-build-job-aws-ecs-fargate
        description: sample-expressjs build step
        packages:
          - git
          - unzip
          - python
        steps:
          - curl https://s3.amazonaws.com/aws-cli/awscli-bundle-1.18.200.zip -o awscli-bundle.zip
          - unzip awscli-bundle.zip && ./awscli-bundle/install -b ~/bin/aws
          - export PATH=~/bin:$PATH
          - aws --version
          - git clone https://$GITHUB_TOKEN:x-oauth-basic@github.com/$ORG/$REPO
          - cd $REPO && ls -asl
          - git fetch && git checkout $REF
          - aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID
          - aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY
          - aws configure set region $AWS_REGION
          - DATE=$(date -u +%Y-%m-%dT%H:%M:%SZ)
          - LOG_STREAM_NAME="CTO.ai-Logs-$DATE"
          - aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_NUMBER.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO
          - docker build -f Dockerfile -t $AWS_ACCOUNT_NUMBER.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO-$STACK_TYPE:$REF .
          - docker push $AWS_ACCOUNT_NUMBER.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO-$STACK_TYPE:$REF
services:
  - name: sample-expressjs-service-aws-ecs-fargate:0.1.1
    description: A sample expressjs service
    run: node /ops/index.js
    port: [ '8080:8080' ]
    sdk: off
    domain: ""
    env:
      static:
        - PORT=8080
    events:
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.merged"
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.opened"
      - "github:workflows-sh/sample-expressjs-aws-ecs-fargate:pull_request.synchronize"
    trigger:
     - build
     - publish
     - start

Ensure to replace my-app and my-repo with your application and repository names, respectively.

Back in your AWS Cloudwatch console, you can select your ECR data and start viewing all your metrics and logs coming from your ECR image.

Next, enter the following commands to create yoru container insights.

- aws logs create-log-group --log-group-name "CTO.ai-Logs"
- aws logs create-log-stream --log-group-name "CTO.ai-Logs" --log-stream-name "$LOG_STREAM_NAME"
- aws logs put-log-events --log-group-name "CTO.ai-Logs" --log-stream-name "$LOG_STREAM_NAME" --log-events timestamp=$(date +%s)000,message="Sample Log Message"

Conclusion

You've now successfully set up CloudWatch logging for AWS ECR using CTO.ai workflows. Now, each time your CTO.ai workflow runs, it will push logs to AWS CloudWatch, helping you monitor and maintain a seamless CI/CD pipeline with detailed logging for your AWS ECR.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

Docker is making it easy to build, deploy, and manage applications at scale. By using containers, Docker provides a lightweight, portable way to package applications along with their dependencies and configurations. In this tutorial, we will learn the fundamentals of creating Docker containers.

What is Docker?

Docker is an open-source platform that automates the deployment of applications inside lightweight and portable containers. It eliminates the it works on my machine problem by standardizing the environment in which applications run, making them independent of the underlying system.

Prerequisites

• Docker installed on your local machine

Setting Up the Docker Environment

Before creating containers, ensure Docker is correctly installed and running:

docker --version

This command returns the Docker version, confirming its installation.

Creating a Dockerfile

A Dockerfile is a text document containing commands used to assemble a Docker image. Before we can create a Dockerfile, we need to create the directory for our Docker project.

mkdir docker_project
cd docker_project

Create a Dockerfile

touch Dockerfile

Edit the Dockerfile

# use an existing image as a base 
FROM python:3.8-slim 

# set the working directory in the container 
WORKDIR /app 

# Copy the dependencies file to the working directory
COPY requirements.txt .

# Install any dependencies 
RUN pip install –no-cache-dir -r requirements.txt 

# Copy the content of the local src directory to the working directory 
COPY src/ . 

# Command to run on container start 
CMD [“python”, “./python_script.py”]

Create a requirements.txt file

List the Python dependencies your application requires, and add your application source code to the src directory.

Building the Docker Image

With the Dockerfile in place, build the image:

docker build -t my_python_app .

This command builds an image from the Dockerfile in the current directory, tagging it as my_python_app.

Running a Container

Once the image is built, run a container from it:

docker run -d -p 5000:5000 my_python_app

This command runs the container in detached mode (-d), mapping port 5000 of the host to port 5000 in the container.

Managing Docker Containers

• List running Containers

docker ps

• Stop a Container:

docker stop [CONTAINER_ID]

• Remove a Container:

docker rm [CONTAINER_ID]

Conclusion

Docker containers offer an efficient and standardized way for application deployment. By following the steps outlined in this tutorial, you can start using Docker for your development and deployment processes.

Now that you know the basics, try integrating Docker with CTO.ai to elevate your CI/CD pipeline, ensuring a uniform and secure environment for the seamless development, testing, and deployment of applications.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!

The synergy and functionality between different technologies in the DevOps and Cloud infrastructure often defines the efficiency and scalability of a system. In this blog, we explore how AWS Cloud Development Kit (CDK), Elastic Kubernetes Service (EKS), Redis, and CTO.ai work in concert to create robust, scalable, and efficient cloud-native applications.

We will be exploring the CTO.ai EC2 ASG CDK Workflow, which is open source in our GitHub Organization.

AWS Cloud Development Kit (CDK) - The Foundation

AWS CDK is an open-source software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation. It provides high-level components that preconfigure cloud resources with sensible defaults, making it easier to build cloud applications.

Elastic Kubernetes Service (EKS) - Orchestrating Containers

Amazon EKS is a managed service that makes it easy to run Kubernetes on AWS without needing to install and operate your own Kubernetes control plane. It's highly scalable and secure, making it an ideal choice for running containerized applications.

Redis - High-Performance Data Store

Redis is an in-memory data structure store used as a database, cache, and message broker. It supports various data structures and is known for its high performance.

CTO.ai - Simplifying Developer Experience

CTO.ai is a platform that simplifies the complexity of DevOps processes, making it more accessible to teams without deep operational expertise. It provides tools and workflows that enhance development and deployment operations.

Integrating Redis with AWS CDK

The integration of Redis into a cloud architecture can be efficiently handled using AWS CDK, as demonstrated in the redis.ts configuration. This script automates the setup of an Elasticache Redis cluster within an AWS environment.

import * as cdk from 'aws-cdk-lib';
import * as elasticache from 'aws-cdk-lib/aws-elasticache';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { Construct } from 'constructs';

interface StackProps {
  vpc: ec2.Vpc
}

class RedisCluster extends Construct {
  public readonly cluster: elasticache.CfnCacheCluster
  constructor(scope: Construct, id:string, props:StackProps) {
    super(scope, id);

    const targetVpc = props.vpc;

    // Define a group for telling Elasticache which subnets to put cache nodes in.
    const subnetGroup = new elasticache.CfnSubnetGroup(this, `${id}-subnet-group`, {
      description: `List of subnets used for redis cache ${id}`,
      subnetIds: targetVpc.privateSubnets.map(function(subnet) {
        return subnet.subnetId;
      })
    });

    // The security group that defines network level access to the cluster
    const securityGroup = new ec2.SecurityGroup(this, `${id}-security-group`, {
      vpc: targetVpc
    });

    securityGroup.addIngressRule(
      ec2.Peer.anyIpv4(),
      ec2.Port.allTraffic(),
      'Allow all connections to redis from inside the VPC'
    );

    // The cluster resource itself.
    this.cluster = new elasticache.CfnCacheCluster(this, `${id}-cluster`, {
      cacheNodeType: 'cache.t2.micro',
      engine: 'redis',
      numCacheNodes: 1,
      autoMinorVersionUpgrade: true,
      cacheSubnetGroupName: subnetGroup.ref,
      vpcSecurityGroupIds: [
        securityGroup.securityGroupId
      ]
    });
  
  }

}

export { RedisCluster as Cluster }

Key components in redis.ts:

• VPC Configuration: It sets up a VPC (Virtual Private Cloud) for secure networking of the services.
• Redis Cluster: It defines an Elasticache Redis cluster, specifying the node type, engine, and other configurations.
• Security and Network: It includes a security group and subnet group setup for the Redis cluster.

Building an EKS Cluster with AWS CDK

The cluster.ts script exemplifies the power of AWS CDK in orchestrating an EKS cluster. It outlines a comprehensive setup including a VPC, security groups, an EKS cluster, a serverless Aurora MySQL database, and a Redis cluster.

import * as cdk from 'aws-cdk-lib';
import * as iam from 'aws-cdk-lib/aws-iam'
import * as ec2 from 'aws-cdk-lib/aws-ec2'
import * as eks from 'aws-cdk-lib/aws-eks'
import * as rds from 'aws-cdk-lib/aws-rds'
import * as sqs from 'aws-cdk-lib/aws-sqs'
import * as elasticache from './redis'
import * as autoscaling from 'aws-cdk-lib/aws-autoscaling'
import { Construct } from 'constructs';

interface StackProps {
  org: string
  env: string
  repo: string
  tag: string
  key: string
  entropy: string
}

export default class Cluster extends cdk.Stack {

  public readonly id: string
  public readonly org: string
  public readonly env: string
  public readonly repo: string
  public readonly tag: string
  public readonly key: string
  public readonly entropy: string

  public readonly vpc: ec2.Vpc
  public readonly cluster: eks.Cluster
  public readonly db: rds.ServerlessCluster
  public readonly mq: sqs.Queue
  public readonly redis: Construct
  public readonly bastion: ec2.BastionHostLinux

  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id)
    this.id = id
    this.org = props?.org ?? 'cto-ai'
    this.env = props?.env ?? 'dev'
    this.key = props?.key ?? 'aws-eks-ec2-asg'
    this.repo = props?.repo ?? 'sample-expressjs-aws-eks-ec2-asg-cdk'
    this.tag = props?.tag ?? 'main'
    this.entropy = props?.entropy ?? '01012022'

    // todo @kc make AZ a StackProp
    const vpc = new ec2.Vpc(this, `${this.id}-vpc`, { 
      cidr: '10.0.0.0/16',
      natGateways: 1,
      maxAzs: 3,
      subnetConfiguration: [
        {
          name: 'Public',
          subnetType: ec2.SubnetType.PUBLIC,
          cidrMask: 24,
        },
        {
          name: 'Private',
          subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
          cidrMask: 24,
        }
      ],
    }); 

    const bastionSecurityGroup = new ec2.SecurityGroup(this, `${this.id}-bastion-sg`, {
      vpc: vpc,
      allowAllOutbound: true,
      description: `bastion security group for ${this.id} cluster`,
      securityGroupName: `${this.id}-bastion-sg`
    });
    bastionSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(22), 'SSH access');

    const bastion = new ec2.BastionHostLinux(this, `${this.id}-bastion`, {
      vpc: vpc,
      instanceName: `${this.id}-bastion`,
      securityGroup: bastionSecurityGroup,
      subnetSelection: {
        subnetType: ec2.SubnetType.PUBLIC
      }
    });

    const cluster = new eks.Cluster(this, `${this.id}-eks`, {
      vpc: vpc,
      defaultCapacity: 0,
      defaultCapacityInstance: ec2.InstanceType.of(ec2.InstanceClass.M5, ec2.InstanceSize.XLARGE),
      version: eks.KubernetesVersion.V1_21,
      mastersRole: new iam.Role(this, 'MastersRole', { assumedBy: new iam.AccountRootPrincipal() })
    });

    const rootVolume: autoscaling.BlockDevice = {
      deviceName: '/dev/xvda', // define the root volume
      volume: autoscaling.BlockDeviceVolume.ebs(100), // override volume size
    };

    // IAM role for our EC2 worker nodes
    const workerRole = new iam.Role(this, `${this.id}-workers` , {
      assumedBy: new iam.ServicePrincipal('ec2.amazonaws.com')
    });

    const onDemandASG = new autoscaling.AutoScalingGroup(this, `${this.id}-asg`, {
      vpc: vpc,
      role: workerRole,
      minCapacity: 1,
      maxCapacity: 10,
      desiredCapacity: 1,
      blockDevices: [rootVolume],
      instanceType: ec2.InstanceType.of(ec2.InstanceClass.M5, ec2.InstanceSize.XLARGE),
      machineImage: new eks.EksOptimizedImage({
        kubernetesVersion: '1.21',
        nodeType: eks.NodeType.STANDARD  // without this, incorrect SSM parameter for AMI is resolved
      }),
      updatePolicy: autoscaling.UpdatePolicy.rollingUpdate()
    });

    cluster.connectAutoScalingGroupCapacity(onDemandASG, {});

    const dbSecurityGroup = new ec2.SecurityGroup(this, `${this.id}-db-sg`, {
      vpc: vpc,
      allowAllOutbound: true,
      description: `db security group for ${this.id} db`,
      securityGroupName: `${this.id}-db-sg`
    });
    dbSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(3306), 'MySQL access');

    const db = new rds.ServerlessCluster(this, `${this.id}-db`, {
      vpc: vpc,
      defaultDatabaseName: `${this.env}`,
      engine: rds.DatabaseClusterEngine.AURORA_MYSQL,
      scaling: { autoPause: cdk.Duration.seconds(0) },
      vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
      securityGroups: [dbSecurityGroup],
      credentials: rds.Credentials.fromGeneratedSecret('root')
    });

    const redis = new elasticache.Cluster(this, `${this.id}-redis`, { vpc: vpc });
    const mq = new sqs.Queue(this, `${this.id}-sqs`);

    this.vpc = vpc;
    this.cluster = cluster;
    this.bastion = bastion;
    this.redis = redis;
    this.db = db;
    this.mq = mq;

    new cdk.CfnOutput(this, `${this.id}VpcId`, { value: this.vpc.vpcId})
    new cdk.CfnOutput(this, `${this.id}ClusterArn`, { value: this.cluster.clusterArn})
    new cdk.CfnOutput(this, `${this.id}DbArn`, { value: this.db?.clusterArn})

  }
}

Key points in cluster.ts:

• EKS Cluster: Establishes an EKS cluster, specifying the version and instance types.
• Worker Nodes: Sets up Auto Scaling Groups for worker nodes, ensuring scalability.
• Aurora MySQL: Integrates a serverless Aurora MySQL cluster, providing a relational database.
• Redis Integration: Incorporates the Redis cluster setup from redis.ts.
• Additional Resources: Sets up other resources like SQS queues and bastion hosts for secure access.

CTO.ai - Orchestrating the Workflow

CTO.ai comes into play by providing the DevOps teams with tools to manage and automate workflows around the infrastructure defined by CDK. It can be used to enhance the deployment process, manage Kubernetes clusters, and monitor the performance of applications.

Conclusion

The combination of AWS CDK, EKS, Redis, and CTO.ai offers a powerful stack for building and managing cloud-native applications. CDK provides the infrastructure-as-code capability, EKS offers a managed Kubernetes service, Redis brings in high-performance data storage, and CTO.ai simplifies the entire DevOps cycle. This integrated approach not only enhances efficiency but also ensures the scalability and reliability of cloud-based applications, making it an ideal choice for modern application development and deployment.

Ready to unlock the power of CTO.ai for your team? Schedule your consultation now with one of our experts today!