mirror of
https://github.com/moghtech/komodo.git
synced 2026-03-09 07:13:36 -05:00
feature: Being able to pick which deployment type you want (GitHub Repo, Docker Image, Compose, or etc) #8
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/komodo#8
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @LawMixer on GitHub (Aug 4, 2024).
Right now, it stands that the application doesn't know which one you want to do, which means if you are only pulling from a GitHub Repo, it will ask you for a builder and an image which really isn't good.
This example is me pulling a GitHub repo and it won't let me pass by without Docker configurations:
https://i.imgur.com/jvjNTOE.png
https://i.imgur.com/uFaRQzl.png
@mbecker20 commented on GitHub (Aug 4, 2024):
Hi, Monitor has different Resource types, see here.
In the screenshot, you have created a "Build", which the only purpose is to build a versioned docker image from the source Dockerfile you provide in the repo.
For Builds, you don't need to specify the Image Registry if you only need the image locally, just leave it as None. Deploying images that are built on the deployment server is not a production level solution, however Monitor supports this.
Let me know if this accomplishes what you want to do.
@mbecker20 commented on GitHub (Aug 4, 2024):
Also, its very easy to deploy Gitea. You can use this as the docker registry, then you can build on a different server (like spawn AWS instances for each build, not expensive). This way, the server running the service won't experience impact if the build uses a lot of resources.
@mbecker20 commented on GitHub (Aug 4, 2024):
The Stack resource, which will be included in v1.13, will also be able to clone a repo with source code on target server, and
docker compose up --buildif you wish. This option is all in one. I think i will be able to release this week.@LawMixer commented on GitHub (Aug 4, 2024):
Man, this is more confusing...let me figure this out.
Each build is giving this error whenever I don't have a Dockerfile in my repo:
https://i.imgur.com/CDPeb9B.png
@mbecker20 commented on GitHub (Aug 4, 2024):
For now, Builds only support creating docker images from a Dockerfile. It makes sense why it would fail here. You can read more about how things work in the build docs here: https://docs.monitor.mogh.tech/docs/build-images
@LawMixer commented on GitHub (Aug 4, 2024):
But..I just want to deploy my GitHub repo and my docker image is set to none, I'm not sure why it's telling me that it's not there whenever it's None:
https://i.imgur.com/kKiHRzi.png
@mbecker20 commented on GitHub (Aug 4, 2024):
Maybe you can tell me a bit more about what you wish to do? Maybe the Repo resource will fit your use better, since you don't need to build a docker image?
@mbecker20 commented on GitHub (Aug 4, 2024):
Also, it will help me to know your experience level using Docker, as using Monitor is mainly coming from how Docker works.
@LawMixer commented on GitHub (Aug 4, 2024):
Oh, I'm sorry for the confusing. Right now, all I'm trying to do is clone my private repo from GitHub and then run it with
python -u start file.I don't have a dockerfile in this repo, and don't wish to use dockerfiles for this project - though I do have this for other projects.
@LawMixer commented on GitHub (Aug 4, 2024):
I was hoping that I could just deploy straight from Repos section, and just configure my start files and all - doesn't seem to be the case, maybe I'm missing something?
@mbecker20 commented on GitHub (Aug 4, 2024):
Monitor will support this, using the Repo resource. But it is barebones:
Monitor can't help any more than this for non-Docker deployments. But to be honest, your use case sounds perfect to Dockerize, you can follow instructions here: https://www.docker.com/blog/how-to-dockerize-your-python-applications/. If you just tell Monitor how to build the image with a Dockerfile in the repo (just one file), you can follow the process I described above, and use Monitor to also see the process status and logs.
Hope this helps.
@LawMixer commented on GitHub (Aug 4, 2024):
This sounds right, but the only thing that stops me from going forward is it requires a docker file which would be hard for me to do.
@mbecker20 commented on GitHub (Aug 4, 2024):
The Repo resource does not require dockerfile
@LawMixer commented on GitHub (Aug 4, 2024):
I think I will just do a dockerfile - I think I'm just going to run in the same deadends I'm running in. Thanks for your help!
@mbecker20 commented on GitHub (Aug 4, 2024):
Sure, let me know if you run into anything else. I'm sorry I don't have the resources to provide more guides in the docs but that will also improve with time. Theres is some helpful info in there though for migrating onto using Docker (this tool was made to help teams migrate onto Docker)
@LawMixer commented on GitHub (Aug 4, 2024):
Thank you - Git wouldn't allow me to commit my changes, so it wouldn't push the new dockerfile that I added...haha my bad!
What's the best way to move files over (redis, mongodb, etc) over to using monitor? Is there any built-in way that I could use? Right now, it's currently on a seperate docker network, and still running.
@mbecker20 commented on GitHub (Aug 5, 2024):
Its a good question, I don't mention this at all in the docs 😬 I'll fix this soon.
Periphery can pick up any containers on the host it is installed on. The network won't be an issue. To add existing containers to Monitor, you can make a deployment with the same name as the container, and set it to be on the same server as where the container is running. Note that if you want a different name for the deployment, first rename the container to the name you want with "docker rename": https://docs.docker.com/reference/cli/docker/container/rename/. Then make the deployment name the same as the name as you just set for container.
Then you should see the container being picked up at this point. You will see the status, Start/stop container, and be able to view the logs.
Monitor is not currently able to import what the Deployment configuration should be from an existing container, so you have to configure things like the image name, network, ports, volumes, environment that is necessary to "Redeploy" the container. Don't forget this, or it won't work to "Redeploy".
@LawMixer commented on GitHub (Aug 5, 2024):
I will wait for the import deployment configuration from an existing container to come out to avoid any issues with me manually doing it - that would probably save me a bunch of time and effort trying to do this all over again..Thank you!
@mbecker20 commented on GitHub (Aug 5, 2024):
Unfortunately, it would be substantial to import the config for running containers to be able to redeploy them, I don't plan support for this any time soon. Just too many edge cases for different users, will just lead to problems.
Recommend you explore a declarative approach to what you run, though. You should already have it stored somewhere how your services are configured? If you set those fields on deployment, it will work. And going forward for you, Monitor will store how everything should be configured in one place.
@LawMixer commented on GitHub (Aug 5, 2024):
Yeah, I could stop my container and then redeploy it with monitor using the same container name, but wouldn't it not have the same configuration or will it keep the same configuration?
@mbecker20 commented on GitHub (Aug 5, 2024):
You can stop / start the container with Monitor, but redeploy will recreate the container with the config you give to Monitor.
@LawMixer commented on GitHub (Aug 5, 2024):
It's on a different network - how would I tell Monitor to use the old configuration or will it stay the same if it's the same container?
@mbecker20 commented on GitHub (Aug 5, 2024):
The container config will stay the same if its just starting / stopping the same container.
@LawMixer commented on GitHub (Aug 9, 2024):
Alright, an update on what I've accomplished! I have migrated 2 of my applications that use GitHub, and I've switched to Dockerfiles to make it easier. The documentation is a bit unclear about it, but all you need to do is:
Builds -> Create a Build -> Fill out your GitHub information and everything -> create a new deployment -> "Redeploy on build" is enabled if you want itI thought I had to use the "Repos" section for it, confusion on my part.
For trying to move database files from one network to another, yes I can just create a new deployment and then name it the same name and then do it that way, but is there anyway currently to import docker inspect files?
docker inspect <container_id>?@mbecker20 commented on GitHub (Aug 9, 2024):
Re using
docker inspect, yes this is the method I considered and it would be really nice to have, however consider it to be outside the Core of what Monitor intends to do well, because I don't know a way to do it without bad edge cases. This makes it more of a liability, and can hurt user trust if they use this import, and on redeploy it breaks their setup. I would rather not provide the feature, and leave it to them to configure how Monitor should deploy.This is what I mean when I say before:
"Unfortunately, it would be substantial to import the config for running containers to be able to redeploy them, I don't plan support for this any time soon. Just too many edge cases for different users, will just lead to problems."
I also will release the Stack feature this weekend. I've finished the backend but still want to improve the docs etc. Stack allows you to deploy with Docker Compose, that way your config is in there and easily portable, it really easy to migrate onto Monitor from deployed using compose on system or Portainer stacks, Dockge, etc. This is quite nice to be honest and I'm curious how it will compare with the Deployment.