任何使用 Gitpod 的开发机器上的 Laravel

2024 年 11 月 9 日

如果您已经是一名开发人员，那么您一定经历过克隆新存储库的兴奋，但很快又会因为无法在您的机器上编译或运行代码而感到沮丧。长期以来，我一直通过使用 Docker 和 Docker Compose 来解决这一挑战，以提供一致的方式在本地构建和测试代码。虽然并不完美，但它是一种改进，但在很多方面仍然不足。但是，如果有一种方法可以拥有一个一致的开发环境，同时还允许标准化和自动化，那会怎样呢？进入吉特波德，一个为解决这些问题而构建的云开发环境。

作为 PHP 和 Laravel 开发人员，我经常为服务器版本、一致的文件打包、数据库迁移以及在本地运行资源而苦恼，以便能够准确地编写代码并测试我的更改。在本文中，我将介绍如何将 Laravel 存储库转变为 Gitpod 项目。从该项目开始，我将重点介绍使用 Gitpod 的 Flex 演练本地代码更改的一些功能，以及任何新开发人员如何通过 Gitpod 平台的强大功能克隆我的存储库并拥有一个完全正常运行的本地环境。

披露

但在开始之前，为了披露，吉特波德赞助我试用他们的产品并报告我的发现。他们吸引了我的注意力，但没有吸引我的意见。以下是我作为一名开发人员在设置 Gitpod Workspace 以在 PHP 和 Laravel 应用程序上进行编码时所获得的客观经验

Gitpod 问题

我从 20 世纪 90 年代中期开始从事开发人员工作，经历过 Gitpod 正在解决的所有问题。这些问题包括设置本地开发、获取构建以及将构建发送到服务器（或云）。这些似乎很重要，但除了单个开发人员的体验之外，还有其他挑战。下图是该工具运行空间的绝佳视觉效果。

在建立了工具和问题之后，让我们进入一些代码，看看 Gitpod 和 Laravel 如何在本地设置下协同工作。

Laravel 应用程序

为了平衡本文，我将使用一个基本的 Laravel 应用程序，该应用程序使用 SQLite 数据库作为其唯一的外部依赖项。完整的源代码可以在这个 Github 存储库

入门

通常，当我启动 Laravel 项目时，我会从以下部分开始：

laravel new example-app

但是，要利用 Gitpod，我需要在容器化环境中构建。为了解决这个问题，我倾向于帆。Sail 为我提供了一种为 Docker 环境构建 PHP 应用程序的方法，并提供了生成的 docker-compose.yml 我可以根据自己的需要进行定制。

所有这些都是为了支持在 DevContainer 中构建和与我的开发环境交互。DevContainers 可以这样描述：

开发容器（简称 dev 容器）允许您将容器用作功能齐全的开发环境。它可用于运行应用程序、分离处理代码库所需的工具、库或运行时，以及帮助进行持续集成和测试。开发容器可以在本地或远程、在私有云或公共云中、在各种支持工具和编辑器中运行 - DevContainers 网站

如果你不熟悉 DevContainers，这是网站这可以让你了解为什么你应该关注和利用它们。

在 Gipod 的上下文中，DevContainer 规范是原生集成的，是开发人员体验不可或缺的一部分。以我为例，以下是 .devcontainers/devcontainer.json 在我的项目中。

{
"name": "Existing Docker Compose (Extend)",
"dockerComposeFile": [
"../docker-compose.yml"
],
"service": "laravel.test",
"workspaceFolder": "/var/www/html",
"customizations": {
"vscode": {
"extensions": [
],
"settings": {}
}
},
"remoteUser": "sail",
"postCreateCommand": "chown -R 1000:1000 /var/www/html 2>/dev/null || true"
}

通过项目设置和进行以下自定义，我的简单应用程序看起来就像项目符号下方的图像一样。

添加了 Todo 模型
添加了 Todo 迁移
添加了 Todo Seeder
定制 TodoView 的 CSS 和 UI
修改路线指向 / 在我的 TodoController 中生成 Todos 列表

深入研究 Gitpod

如果您与开发具有 2 个以上依赖项的任何应用程序的开发人员交谈，他们会告诉您相同的共同痛点。操作系统和库级别的依赖项管理可能很麻烦。保持与应用程序一致的最新数据库需要付出努力。他们经常忘记运行迁移，并浪费了数小时的时间才意识到他们需要运行迁移。或者更糟糕的是，他们加入了一个新团队，并浪费了很多天的时间才完成项目配置。

现在，把所有这些以及在本地完成工作所需的工作都考虑进去，然后尝试将这些努力带给 DevOps 和平台团队。这几乎就像从头开始，并且可能是本地和云之间脆弱的转换之舞。想象一下能够同时满足开发团队和平台团队的需求。这就是 Gitpod 所面临的问题和空间。

下面我的例子只是浅显的介绍。它将使用 PHP、Laravel、DevContainers、Gitpod 的 Flex、本地 Gitpod Runner 和一些基本的 Gitpod Automations。然后，我将向您介绍一些可以加快学习速度的后续步骤。

Gitpod 项目和环境

Gitpod 围绕项目和环境运行。我的项目直接连接到我上面分享的 Github 存储库。在 UI 中，它显示在“项目”视图中。

一旦我建立了项目，我就可以创建一个环境。环境可以有 Runner，也就是托管容器的地方。对我来说，我在本地 Runner 中运行，但这很容易成为 AWS 中的一个区域，在那里我会在我选择的 VPC 和子网中运行 EC2 服务器。

本地跑者

在 Gitpod 中建立这两个基本构造后，我就可以启动本地环境了。这就是 DevContainer 的作用所在。Gitpod 将读取该规范，该规范指向一个 Docker Compose 文件，该文件将启动我可以在其中编写代码的容器。

services:
    laravel.test:
        build:
            context: './.devcontainer'
            dockerfile: Dockerfile
            args:
                WWWGROUP: '1000'
        image: 'sail-8.3/app'
        extra_hosts:
            - 'host.docker.internal:host-gateway'
        ports:
            - '${APP_PORT:-80}:80'
            - '${VITE_PORT:-5173}:${VITE_PORT:-5173}'
        environment:
            WWWUSER: '1000'
            LARAVEL_SAIL: 1
            XDEBUG_MODE: '${SAIL_XDEBUG_MODE:-off}'
            XDEBUG_CONFIG: '${SAIL_XDEBUG_CONFIG:-client_host=host.docker.internal}'
            IGNITION_LOCAL_SITES_PATH: '${PWD}'
        volumes:
            - '.:/var/www/html'
        networks:
            - sail
        depends_on: {  }
networks:
    sail:
        driver: bridge

当我点击启动，一切顺利时，我得到了以下带有所有这些绿色圆圈的图像。红色圆圈会很糟糕，我会有日志并了解可能出了什么问题。

自动化

此时，您可能想知道图像中下部的服务和任务是什么。Gitpod 不仅仅是 DevContainers，还让您能够自定义启动方式。自动化功能强大，可以实现更多功能请阅读此处。

本质上，可以这样想。我在启动时获得积分，可以针对容器运行命令。例如，也许我想运行数据库迁移。或者也许我想 compose 我的 Laravel 应用程序需要一些依赖项吗？这些将被称为任务。

但是像 PHP 应用程序本身这样长时间运行的东西怎么办呢？这些可以通过服务来完成。所有这些自动化都是通过包含一个 .gitpod/automations.yaml 我项目中的文件。就我而言，它如下所示。我选择了粒度，而不是在一个任务中完成所有操作，只是为了更好地可视化事物。

services:
  php:
    name: Run PHP Serve
    triggeredBy: ["postDevcontainerStart"]
    commands:
      start: php artisan serve

tasks:
  copyEnv:
    name: Copy Environment
    description: Creates the .env file
    triggeredBy:
      - postEnvironmentStart
    command: cp .env.example .env
  appUrl:
    name: Mod App URL
    dependsOn: ["copyEnv"]
    triggeredBy:
      - postEnvironmentStart
    command: sed -i "s#APP_URL=http://localhost#APP_URL=$(gp url 8000)#g" .env
  viteUrl:
    name: Mod Vite URL
    dependsOn: ["copyEnv"]
    triggeredBy:
      - postEnvironmentStart
    command: sed -i "s#GITPOD_VITE_URL=#GITPOD_VITE_URL=$(gp url 5173)#g" .env
  composer:
    name: Install Dependencies
    dependsOn: ["copyEnv"]
    triggeredBy:
      - postEnvironmentStart
    description: Installs deps via composer
    command: composer install --ignore-platform-reqs
  createDatabase:
    name: Create Database
    triggeredBy:
      - postEnvironmentStart
    dependsOn: ["copyEnv"]
    command: touch database/database.sqlite
  phpOperations:
    name: Setup PHP and Run
    triggeredBy:
      - postEnvironmentStart
    dependsOn: ["copyEnv"]
    command: |
      php artisan key:generate
      php artisan storage:link
      php artisan migrate --seed
      php artisan db:seed --class=TodoSeeder

太棒了，对吧？！？当我启动开发环境时，我可以运行这些步骤。任何有权访问此项目的开发人员都可以获得相同的结果。假设我需要在下次启动时更改步骤或工作流程。这些步骤或工作流程只需运行即可。这比 README.md 文件好多了，可能已经过时了。

连接到我的编辑器

使用 Gitpod 客户端时，我可以将编辑器或终端连接到容器。为此，我选择了 VSCode，因为它很受欢迎。但是，它有一个 Jetbrains IDE 集成，我也可以通过自定义 Dotfiles 在 Neovim 中连接我最喜欢的编辑器。这种支持鼓励了我内心的终端开发人员，我计划在有时间的时候在这个领域进行更深入的研究。

VSCode 有两个不错的扩展，可用于 Gitpod 和 DevContainers。我发现，一旦我在 VSCode 中启动我的 Gitpod 环境，它就像在进行正常的本地开发一样。更改可立即使用，所有正常的 Git 操作都按我预期的方式执行。同样，所有这些都发生在容器中，因此无需担心本地依赖关系或“它在我的机器上运行良好”。

最后一步是确保我的容器中暴露了端口，这样我就可以服务于正在运行的 Gitpod 服务的流量，这只是 php artisan serve 。一切就绪后，我就能够在浏览器中为流量提供服务，该流量显示一个 PHP Laravel 应用程序，该应用程序由 SQLite 支持，该应用程序已按照我的任务自动化指定的方式进行迁移和播种。

最棒的是，我可以与任何队友分享这一点，在提取 Gitpod 和 DevContainer 资源、初始化和启动所需的时间内，他们将获得相同的体验。解决了许多问题。

印象与思考

我过去没有花太多时间在 CDE 上，但我对 Gitpod 所做的工作印象深刻。我认为它的强大之处在于可重复性，能够以一致的方式自动执行如此多的常规任务，而这些方式与运行时无关，这简直是魔术。

在本文中，我没有机会探索如何在云中运行项目，但从我对文档的探索来看，我可以通过生成的 CloudFormation 模板将同一个项目连接到 AWS。而且由于 Gitpod 带有 CLI，所以我在本地执行的相同工作可以作为 CI/CD 流程的一部分连接到自动化管道，从而可以加速向客户交付价值。

不过，一路上我确实遇到了一些挫折。Gitpod 最近推出了他们的 Flex 产品，本文就是基于该产品撰写的。

首先，文档很好，但教程有些不足，所以我确实对一些具体模式以及客户端 UI 的工作原理有一些了解。希望本文和随附的代码能帮您免去其中的一些麻烦。

其次，对于早期版本来说，UI 非常好，但仍然缺少一些选项，例如，如果我更改了一些基本内容，则需要刷新我的 Git 存储库。我发现，当转到新的 CLI 时，我无法执行我认为可以从文档中执行的操作。

然而，软件的出色性能完全抵消了这些缺陷。再加上 Gitpod 的 Github 存储库的活跃开发周期，随着 Flex 的持续发展，情况只会越来越好。我对这可以为大型软件开发团队提供的工作流程和时间节省感到非常满意。

包起来

我写这篇文章的目的是提供使用 DevContainers 和 Flex UI Client 在 Gitpod 中开发的 Laravel 应用程序运行的基本介绍。生态系统中还有更多值得探索的内容。您可以深入了解 Gitpod、DevContainers 规范，或改进我在这个项目中使用的基础 Dockerfile。

我认为 CDE 方法的强大之处在于，作为开发人员，你可以更好地与平台团队合作，通过使用以下抽象来分担部署和配置的一些负担：吉特波德提供。通过采用这种方法，您还可以获得高水平的隔离和安全性。环境可以隔离到工作站或服务器。您还可以使用租户级配置。最后，您执行的每个操作都经过 Gitpod API 中的凭据和授权的审查。

发展正在快速推进。这种方法让您能够掌控并安心，确保您的日常工作的基础得到控制、管理和保护。

感谢您的阅读并祝您搭建愉快！

帖子任何使用 Gitpod 的开发机器上的 Laravel 首先出现在 Laravel 新闻。

加入 Laravel 时事通讯获取最新信息类似这样的 Laravel 文章将直接发送到您的收件箱。