Конечно! Kubectl это инструмент написанный на Go, cli интерфейс для работы с вашим кластером. Кажется что вам лучше использовать обычный minikube, разворачивается в 1 клик на одной виртуальной машине, даже делить ничего не потребуется.
Если все же хочется использовать kubesphere, например из-за удобной веб-панели, то смело используйте материал из моей статьи, но, будет проще пропустить первый шаг и арендовать 3 виртуальных сервера (у каждого сервера будет публичный IP). Это позволит избежать проблем с проксированием запросов к кластеру.
Не вижу тут противоречия, если честно, из официальной документации kubectl:
# Get commands with basic output
kubectl get services # List all services in the namespace
kubectl get pods --all-namespaces # List all pods in all namespaces
kubectl get pods -o wide # List all pods in the current namespace, with more details
kubectl get deployment my-dep # List a particular deployment
kubectl get pods # List all pods in the namespace
kubectl get pod my-pod -o yaml # Get a pod's YAML
Однако команда kubectl get pod равнозначна команде kubectl get pods
В ближайшем будущем появится возможность просматривать не только активные окружения, но так же и другие сущности, как и фильтровать их по имени окружения, активным боксам и так далее. Команда get идеально подходит для таких вещей, а сущности, которые мы хотим получить, могут иметь кучу удобных для пользователя алиасов.
На другом примере из kubectl можно посмотреть на команды ниже, которые вернут один и тот же результат.
kubectl get services
kubectl get service
kubectl get svc
Скорее всего в следующей версии k8sbox будет реализовано получение списка окружений с помощью следующих команд:
k8sbox get environments
k8sbox get environment
k8xbox get env
Я активно работаю над этим и стараюсь сделать проект максимально понятными для пользователя такого высокоуровневого инструмента как k8sbox. Однако если есть крутые идеи - с радостью буду ждать пулл реквестов)
Я старался сделать интерфейс схожим с kubectl и его командами, так как планируется добавлять множество команд для просмотра статистики и разделения уже задеплоеных окружений. get и describe кажутся идеально подходящими, хотя вероятно стоит добавить к ним шорткаты.
А почему бы не сохранять toml-файл в установленном окружении. Тогда удалять окружение можно (и нужно, по логике) по имени -
Изначально был план сделать отдельный файл для окружений, по примеру с terraform, однако понял что будет излишне. Отсюда и такой не очень интуитивный механизм удаления
environment.toml всегда лежит где-то рядом обычно, скорее всего в репозитории в котором лежат другие деплойменты. Однако сами окружения (их описания) сохраняются в /tmp/k8sbox/saves в json формат. Именно так можно посмотреть что мы уже раскатили и детали окружения с помощью команды k8sbox describe {EnvironmentID}
Удаление по ID окружения - как раз то над чем сейчас работаю, будет уже на неделе, как, думаю, и шорткаты для основных команд)
Не совсем, мы создаем feature-ветку от мастера. Пишем в ней код, затем именно эту ветку раскатываем как stage-environment (в моем примере с помощью k8sbox) и тестируем ее отдельно от dev/prod окружений.
Как только фича протестирована - мы мержим ее в мастер. Из мастера можно настроить автоматический деплой в dev-environment при каждом новом пуше.
Перед публикацией релиза в прод - желательно проверить как будут вести себя все ваши фичи на dev-окружении, не будут ли они конфликтовать друг с другом.
Если все ок - отбиваем тег и выкатываем в прод. Если какая-то фича с багом - делаем revert мерж-коммита конкретной фичи и отправляем на доработку, а релиз выпускаем без нее.
В мастере желательно хранить только протестированный на stage-feature-окружениях код. Однако если все же баг нашли в мастере и от него уже ответвились другие разработчики - после фикса и мержа этого фикса в мастер - пускай они просто подтянут новые изменения перед созданием своего merge-request
Действительно, забыл добавить данный флаг в статью. Обновил
Конечно! Kubectl это инструмент написанный на Go, cli интерфейс для работы с вашим кластером. Кажется что вам лучше использовать обычный minikube, разворачивается в 1 клик на одной виртуальной машине, даже делить ничего не потребуется.
Если все же хочется использовать kubesphere, например из-за удобной веб-панели, то смело используйте материал из моей статьи, но, будет проще пропустить первый шаг и арендовать 3 виртуальных сервера (у каждого сервера будет публичный IP). Это позволит избежать проблем с проксированием запросов к кластеру.
Не вижу тут противоречия, если честно, из официальной документации kubectl:
Однако команда
kubectl get podравнозначна командеkubectl get podsВ ближайшем будущем появится возможность просматривать не только активные окружения, но так же и другие сущности, как и фильтровать их по имени окружения, активным боксам и так далее. Команда get идеально подходит для таких вещей, а сущности, которые мы хотим получить, могут иметь кучу удобных для пользователя алиасов.
На другом примере из kubectl можно посмотреть на команды ниже, которые вернут один и тот же результат.
Скорее всего в следующей версии k8sbox будет реализовано получение списка окружений с помощью следующих команд:
Я активно работаю над этим и стараюсь сделать проект максимально понятными для пользователя такого высокоуровневого инструмента как k8sbox. Однако если есть крутые идеи - с радостью буду ждать пулл реквестов)
Я старался сделать интерфейс схожим с kubectl и его командами, так как планируется добавлять множество команд для просмотра статистики и разделения уже задеплоеных окружений. get и describe кажутся идеально подходящими, хотя вероятно стоит добавить к ним шорткаты.
Изначально был план сделать отдельный файл для окружений, по примеру с terraform, однако понял что будет излишне. Отсюда и такой не очень интуитивный механизм удаления
environment.toml всегда лежит где-то рядом обычно, скорее всего в репозитории в котором лежат другие деплойменты. Однако сами окружения (их описания) сохраняются в /tmp/k8sbox/saves в json формат. Именно так можно посмотреть что мы уже раскатили и детали окружения с помощью команды
k8sbox describe {EnvironmentID}Удаление по ID окружения - как раз то над чем сейчас работаю, будет уже на неделе, как, думаю, и шорткаты для основных команд)
Не совсем, мы создаем feature-ветку от мастера. Пишем в ней код, затем именно эту ветку раскатываем как stage-environment (в моем примере с помощью k8sbox) и тестируем ее отдельно от dev/prod окружений.
Как только фича протестирована - мы мержим ее в мастер. Из мастера можно настроить автоматический деплой в dev-environment при каждом новом пуше.
Перед публикацией релиза в прод - желательно проверить как будут вести себя все ваши фичи на dev-окружении, не будут ли они конфликтовать друг с другом.
Если все ок - отбиваем тег и выкатываем в прод. Если какая-то фича с багом - делаем revert мерж-коммита конкретной фичи и отправляем на доработку, а релиз выпускаем без нее.
В мастере желательно хранить только протестированный на stage-feature-окружениях код. Однако если все же баг нашли в мастере и от него уже ответвились другие разработчики - после фикса и мержа этого фикса в мастер - пускай они просто подтянут новые изменения перед созданием своего merge-request
Решение правильное, но для ЧПУ неймспейсы из RouteServiceProvider убираем и используем полный путь в самих роутах:
Route::get('/test', [TestController::class, 'index']);Так и роуты читаемые и легко в иде перейти в нужный контроллер.