Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Support for DevFile Spec 2+ #113

Open
michaelbrewer opened this issue Mar 25, 2024 · 3 comments
Open

Add Support for DevFile Spec 2+ #113

michaelbrewer opened this issue Mar 25, 2024 · 3 comments

Comments

@michaelbrewer
Copy link
Contributor

michaelbrewer commented Mar 25, 2024

What is devfiles?

"You can use devfiles to automate and simplify your development process by adopting the existing devfiles that are available in the public community registry or by authoring your own devfiles to record custom instructions to configure and run your build environment as a YAML-formatted text file." - See https://devfile.io/docs/2.2.2/what-is-a-devfile

Benefits of devfile

Much like the devcontainer spec, devfile spec has a number of features.

Devfiles include the following features:

  • Guidance for using runtime images
  • Example code
  • Build and CI commands
  • Deployment options

Devfiles have the following benefits:

  • Reduce the gap between development and deployment
  • Find available devfile stacks or samples in a devfile registry
  • Produce consistent build and run behaviors

Main benefits from these that differ from devcontainer are:

  • Not limited to vscode
  • Has a catalog of defined templates
  • Includes support for starter projects, so bluepints can be built into the spec.
  • Interoperability with OpenShift and Gitlab workspaces
  • Multi-container development environments (which would be beyond the spec of envbuilder but maybe more for coder as a product)

AI Generated differents

The devfile spec is a vendor-neutral definition for cloud-native dev workspaces, whereas the devcontainer spec is a Docker extension that aims to simplify local development.

  • Devfile
    • Describes the structure of a cloud-native devworkspace and development environment.
    • Can be used to define and manage dev workspaces in any cloud environment.
    • Supports a wider range of features, including:
      • Multi-container development environments
      • Kubernetes-based deployments
      • Support for multiple projects and starter projects
      • Pluggable tooling integrations
  • Devcontainer
    • Focused on providing a simple and consistent way to define and manage local development environments for Docker containers.
    • Supports a more limited range of features, including:
      • Single-container development environments
      • Docker-based deployments
      • Basic support for project syncing and environment variables
    • Typically used for local development on a single machine, not for managing dev workspaces in a cloud environment.

Some examples

Java Spring Boot

schemaVersion: 2.1.0
metadata:
  name: java-springboot
  displayName: Spring Boot®
  description: Java application using Spring Boot® and OpenJDK 11
  icon: https://raw.githubusercontent.com/devfile-samples/devfile-stack-icons/main/spring.svg
  tags:
    - Java
    - Spring
  projectType: springboot
  language: Java
  version: 1.3.0
  globalMemoryLimit: 2674Mi
starterProjects:
  - name: springbootproject
    git:
      remotes:
        origin: "https://github.com/odo-devfiles/springboot-ex.git"
components:
  - name: tools
    container:
      image: registry.access.redhat.com/ubi9/openjdk-17:1.17-1.1705573248
      command: ["tail", "-f", "/dev/null"]
      memoryLimit: 768Mi
      mountSources: true
      endpoints:
        - name: http-springboot
          targetPort: 8080
        - exposure: none
          name: debug
          targetPort: 5858
      volumeMounts:
        - name: m2
          path: /home/user/.m2
      env:
        - name: DEBUG_PORT
          value: "5858"
  - name: m2
    volume:
      size: 3Gi
commands:
  - id: build
    exec:
      component: tools
      workingDir: ${PROJECT_SOURCE}
      commandLine: "mvn clean -Dmaven.repo.local=/home/user/.m2/repository package -Dmaven.test.skip=true"
      group:
        kind: build
        isDefault: true
  - id: run
    exec:
      component: tools
      workingDir: ${PROJECT_SOURCE}
      commandLine: "mvn -Dmaven.repo.local=/home/user/.m2/repository spring-boot:run"
      group:
        kind: run
        isDefault: true
  - id: debug
    exec:
      component: tools
      workingDir: ${PROJECT_SOURCE}
      commandLine: "java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=${DEBUG_PORT},suspend=n -jar target/*.jar"
      group:
        kind: debug
        isDefault: true

NextJS project

schemaVersion: 2.1.0
metadata:
  name: nodejs-nextjs
  displayName: Next.js
  description: "Next.js gives you the best developer experience with all the features you need for production:
    hybrid static & server rendering, TypeScript support, smart bundling, route pre-fetching, and more.
    No config needed."
  icon: https://raw.githubusercontent.com/devfile-samples/devfile-stack-icons/main/next-js.svg
  tags:
    - Node.js
    - Next.js
  projectType: Next.js
  language: TypeScript
  provider: Red Hat
  version: 1.0.3
starterProjects:
  - name: nodejs-nextjs-starter
    git:
      checkoutFrom:
        revision: main
      remotes:
        origin: https://github.com/devfile-samples/devfile-stack-nodejs-nextjs.git
components:
  - container:
      endpoints:
        - name: http-nextjs
          targetPort: 3000
      image: registry.access.redhat.com/ubi8/nodejs-16:1-153
      command: ['tail', '-f', '/dev/null']
      memoryLimit: 1024Mi
    name: runtime
commands:
  - exec:
      commandLine: npm install
      component: runtime
      group:
        isDefault: true
        kind: build
      workingDir: ${PROJECT_SOURCE}
    id: install
  - exec:
      commandLine: npm run dev
      component: runtime
      group:
        isDefault: true
        kind: run
      hotReloadCapable: true
      workingDir: ${PROJECT_SOURCE}
    id: run

DotNet project

schemaVersion: 2.2.0
metadata:
  name: dotnet-basic
  displayName: Basic .NET
  version: 1.1.1
  icon: https://github.com/dotnet/brand/raw/main/logo/dotnet-logo.png
  provider: Red Hat
  supportUrl: https://github.com/devfile-samples/devfile-support#support-information
  language: .NET
  projectType: dotnet
  tags:
    - .NET
  attributes:
    alpha.dockerimage-port: 8081
starterProjects:
  - name: s2i-example
    git:
      checkoutFrom:
        remote: origin
        revision: dotnet-6.0
      remotes:
        origin: https://github.com/redhat-developer/s2i-dotnetcore-ex
    subDir: app
components:
  - name: dotnet
    container:
      image: registry.access.redhat.com/ubi8/dotnet-60:6.0
      command: ['tail', '-f', '/dev/null']
      mountSources: true
      env:
        - name: CONFIGURATION
          value: Debug
        - name: STARTUP_PROJECT
          value: app.csproj
        - name: ASPNETCORE_ENVIRONMENT
          value: Development
      endpoints:
        - name: http-8080
          targetPort: 8080
  - name: image-build
    image:
      imageName: 'dotnet-image:latest'
      dockerfile:
        uri: docker/Dockerfile
        buildContext: .
        rootRequired: false
  - name: kubernetes-deploy
    attributes:
      deployment/replicas: 1
      deployment/cpuRequest: 10m
      deployment/memoryRequest: 100Mi
      deployment/container-port: 8081
    kubernetes:
      uri: kubernetes/deployment.yaml
      endpoints:
        - name: http-8081
          targetPort: 8081
          path: /
          secure: true
  - name: kubernetes-service
    attributes:
      deployment/replicas: 1
      deployment/cpuRequest: 10m
      deployment/memoryRequest: 100Mi
      deployment/container-port: 8081
    kubernetes:
      uri: kubernetes/service.yaml
commands:
  - id: build
    exec:
      workingDir: ${PROJECT_SOURCE}
      commandLine: kill $(pidof dotnet); dotnet build -c $CONFIGURATION $STARTUP_PROJECT /p:UseSharedCompilation=false
      component: dotnet
      group:
        isDefault: true
        kind: build
  - id: run
    exec:
      workingDir: ${PROJECT_SOURCE}
      commandLine: dotnet run -c $CONFIGURATION --no-build --project $STARTUP_PROJECT --no-launch-profile
      component: dotnet
      group:
        isDefault: true
        kind: run
  - id: build-image
    apply:
      component: image-build
  - id: deploy-deployment
    apply:
      component: kubernetes-deploy
  - id: deploy-service
    apply:
      component: kubernetes-service
  - id: deploy
    composite:
      commands:
        - build-image
        - deploy-deployment
        - deploy-service
      group:
        isDefault: true
        kind: deploy
@kylecarbs
Copy link
Member

I think we could do this quite easily if demand is there.

The devcontainer dir already abstracts that part of the project well.

@michaelbrewer
Copy link
Contributor Author

One of the features i like is built in support for project templates starterProjects

@marrotte
Copy link

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants