search

wballard / starphleet

19 stars 37 forks source link

Support docker images #361

Open fearphage opened 6 years ago

fearphage commented 6 years ago

This seems like a relatively straight forward process aside from pulling down the images from a central repository (dockerhub?).

Question

Would it be better/more beneficial to fork the startup, stop, etc. scripts to be able to control docker containers OR just make devs use the raw docker commands instead? I'm in favor of the latter, but I do see the benefits of a unified way to do all the things.

Benefits

Why

Logging/debugging applications has really been a tough part of getting up to speed with the Starphleet process for me. This side steps much of that while providing additional benefits.

Considerations

I tried upgrading the version of lxc used to get the native support for docker images, but all of the Starphleet scrips are tightly coupled to the version we're using so it doesn't seem like a worthwhile route to explore honestly.

Thoughts, concerns, etc?

bhudgens commented 6 years ago

Regarding the Benefits

I do not see the value in trying to reinvent docker or try to be compatible with docker. There are other services better suited and a full ecosystem built around docker. Starphleet should move to being agnostic to the backend service delivery mechanism.

fearphage commented 6 years ago

Starphleet can be run locally utilizing virtualization software

I don't want to run Starphleet locally necessarily. I want to build my application locally.

I don't see the value of re-inventing docker. Instead - use docker and route to the exposed service.

I agree with that 100%. I wasn't suggesting re-inventing docker in any form or fashion. The goal of this issue and any resulting code (if any) would be to "use docker and route to the exposed service".

Logs are already isolated in the current containers in addition to aggregate.

I understand and that's good to know.

Instead of using containers - we use node buildpacks.

Why not both?

bhudgens commented 6 years ago

I don't want to run Starphleet locally necessarily. I want to build my application locally.

I believe you are saying that while developing, you don't want to run Starphleet locally but you want to run Docker locally. It seems like you don't want to use Starphleet - so, don't! Starphleet !== Docker. Developing against Docker is a great way to develop. Trying to shove more support of docker into Starphleet is rebuilding already working solutions that evolved after Starphleet existed. The better solution would be to enable Starphleet to talk to a docker backend that already supports docker containers.

The goal of this issue and any resulting code (if any) would be to "use docker and route to the exposed service".

I understood this issue as you had invested time upgrading and messing with LXC and you wanted to find a way to have Starphleet natively support Docker containers. If your intention was to modify the NGINX configuration to reach out to a Docker platform - this concept is something we have discussed as our migration path towards a docker, kube, and/or lamda/serverless platform. We do want to allow Starphleet to natively support other backend systems. Right now, it's possible via proxy but not native.

Instead of using containers - we use node buildpacks - Why not both?

The docker-container-hosting problem has already been solved in a robust, open source, open platform kind of way and re-performing the work seems counter to the point of Starphleet. The evolution of Starphleet should be to utilize other platforms.. not reinvent them. Kube / Docker Swarm already exist. Instead of focusing on Docker - Starphleet should evolve to being agnostic to what containerization service it delivers.

fearphage commented 6 years ago

It seems like you don't want to use Starphleet - so, don't!

I don't have anything against Starphleet personally. I just want to debug and develop apps easily and conveniently honestly. Everything else is details. I am frustrated with the difficulties I'm facing and I was attempting to bring solutions to the table instead of merely complaining.

The better solution would be to enable Starphleet to talk to a docker backend that already supports docker containers.... We do want to allow Starphleet to natively support other backend systems. Right now, it's possible via proxy but not native.

Can you elaborate on that at all? Possibly point me to a branch if possible. I heard chatter about lambda/FAAS support for instance.

I'm interested in incorporating this the right way™. This issue was me suggesting a quick, cheap way to move forward.

bhudgens commented 6 years ago

I don't have anything against Starphleet personally. I just want to debug and develop apps easily and conveniently honestly. Everything else is details. I am frustrated with the difficulties I'm facing and I was attempting to bring solutions to the table instead of merely complaining.

This isn't clear. Plenty of people develop apps easily and conveniently every day. 100's of them. Your difficulties do not seem to be articulated.

Can you elaborate on that at all? Possibly point me to a branch if possible. I heard chatter about lambda/FAAS support for instance.

There is an effort towards supporting AWS lambda natively. There is an open PR you can review.

I'm interested in incorporating this the right way™. This issue was me suggesting a quick, cheap way to move forward.

I'm not sure there's a clear answer to this. Starphleet does not natively support a proxy to backend services. It's a concept that has been discussed. In the meantime, there are lightweight deployable services that take a config from the orders that proxy to any backend system.

fearphage commented 6 years ago

Plenty of people develop apps easily and conveniently every day. 100's of them.

Hundreds of people can solve a Rubik's cube while blindfolded easily and conveniently. That doesn't mean the task itself is easy and convenient. It means they are accustomed to their environment. Knowing something inside out so that you know where the bodies are buried and having a process be drop-dead simple are two different things entirely.

We were just talking fondly about grepping logs. I still have to start zgreping files/folders and come back to it after lunch/a break sometimes to find what I need. I think we just have very different ideas of convenience and ease of use. Keep in mind that I have absolutely no intention to belittle the work you've done with the captain's logs (well-played on the naming by the way :wink:). Based on the responses it is a big advancement in logging tooling, but I assure you logging can be so much more than that and more easily accessed, searched, parsed, manipulated, etc. I have experienced the future firsthand. *nix utilities are extremely powerful and dependable, but they are not the most convenient in my experience. (Dev)Ops tooling has come such a long way since the advent of those tools. They are great to have in your bag, but in most cases they are generally the last resort.

Your "difficulties" do not seem to be articulated.

The most recent incarnation of my "difficulties" is trying to understand why a job fails when run as a cron job, but succeeds when I run the same command manually as the same user (ubuntu). When run as a cron, all calls to aws (even aws --version) fail saying it can't find a botocore python dependency. Copying and pasting the line from sh_at and running it manually runs to a much later point in the process with no problem executing any aws commands. I'm trying to determine what's different about the environment, executables, etc. in these two cases.

Thanks for the PR reference. I hadn't seen that. I understand there is no easy answer, but I'll keep looking for opportunities to simplify things if possible.

bhudgens commented 6 years ago

That doesn't mean the task itself is easy and convenient. It means they are accustomed to their environment.

Agree. The response to your point is, well, your point.

"It means they are accustomed to their environment"

You seem accustomed to docker and thus it is comfortable for you. You should perhaps continue to use it? We do not impose restrictions on the technology used by your project. I think there is pretty much a consensus that had Docker been mature we would have used it. However, we no longer want to be in the infrastructure business and utilizing Docker is heading in the wrong direction.

I noticed you heavily amended your Dev environment in an effort to implement/explore docker and Starphleet? I would encourage you to run a dev environment that mimics the production environment. I can't think of any reason upgrading LXC would benefit you in working on applications for the company. When the bots setup your dev machine - leave the machine in the same state with the same versions as production. It's possible your issues are related to utilizing newer versions of LXC and are self imposed? I am aware of at least one change to the behavior of LXC that modified logging.

I assure you logging can be so much more than that and more easily accessed, searched, parsed, manipulated, etc.

Do you feel you are aware of logging solutions that we have not considered? What are these solutions you're referring to and how do they relate to this feature request for Starphleet? Maybe open a different issue related to logging and how it should be improved inside Starphleet?

no intention to belittle the work you've done with the captain's logs

I'm not sure how the captain's log setup is related to this thread nor do I feel belittled. The captain user is a 'read only' user. The log setup was a replacement for the non-used Kibana. Neither are related to docker?

The most recent incarnation of my "difficulties" is trying to understand why a job fails when run as a cron job, but succeeds when I run the same command manually as the same user (ubuntu). When run as a cron, all calls to aws (even aws --version) fail saying it can't find a botocore python dependency. Copying and pasting the line from sh_at and running it manually runs to a much later point in the process with no problem executing any aws commands. I'm trying to determine what's different about the environment, executables, etc. in these two cases.

This doesn't sound like a problem with Starphleet. It sounds like an issue with the environment inside your container. I would start by having the bot destroy/create your dev environment so it is back inline with production. I would then start troubleshooting locally in your dev environment until the issue is resolved. It will work in production if it works in your unaltered dev environment.

wballard commented 6 years ago

I think Pred loves infra — and maybe is working on the wrong thing by doing apps :) maybe should join the fire crew.

But — self containerization is 5 year old news, full PaaS ‘infrastructure- less’ is the way forward on services and databases.

On Apr 11, 2018, at 8:46 AM, Benjamin Hudgens notifications@github.com wrote:

That doesn't mean the task itself is easy and convenient. It means they are accustomed to their environment.

Agree. The response to your point is, well, your point.

"It means they are accustomed to their environment"

You seem accustomed to docker and thus it is comfortable for you. You should perhaps continue to use it? We do not impose restrictions on the technology used by your project. I think there is pretty much a consensus that had Docker been mature we would have used it. However, we no longer want to be in the infrastructure business and utilizing Docker is heading in the wrong direction.

I noticed you heavily amended your Dev environment in an effort to implement/explore docker and Starphleet? I would encourage you to run a dev environment that mimics the production environment. I can't think of any reason upgrading LXC would benefit you in working on applications for the company. When the bots setup your dev machine - leave the machine in the same state with the same versions as production. It's possible your issues are related to utilizing newer versions of LXC and are self imposed? I am aware of at least one change to the behavior of LXC that modified logging.

I assure you logging can be so much more than that and more easily accessed, searched, parsed, manipulated, etc.

Do you feel you are aware of logging solutions that we have not considered? What are these solutions you're referring to and how do they relate to this feature request for Starphleet? Maybe open a different issue related to logging and how it should be improved inside Starphleet?

no intention to belittle the work you've done with the captain's logs

I'm not sure how the captain's log setup is related to this thread nor do I feel belittled. The captain user is a 'read only' user. The log setup was a replacement for the non-used Kibana. Neither are related to docker?

The most recent incarnation of my "difficulties" is trying to understand why a job fails when run as a cron job, but succeeds when I run the same command manually as the same user (ubuntu). When run as a cron, all calls to aws (even aws --version) fail saying it can't find a botocore python dependency. Copying and pasting the line from sh_at and running it manually runs to a much later point in the process with no problem executing any aws commands. I'm trying to determine what's different about the environment, executables, etc. in these two cases.

This doesn't sound like a problem with Starphleet. It sounds like an issue with the environment inside your container. I would start by having the bot destroy/create your dev environment so it is back inline with production. I would then start troubleshooting locally in your dev environment until the issue is resolved. It will work in production if it works in your unaltered dev environment.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

fearphage commented 6 years ago

I noticed you heavily amended your Dev environment in an effort to implement/explore docker and Starphleet?

My environment is pristine. I destroyed and made a new instance after testing the latest version of lxc.

You seem accustomed to docker and thus it is comfortable for you.

I've used lots of logging tools and stacks outside of docker, kubernetes, and the likes. Docker is not the thing that makes logging easy.

Do you feel you are aware of logging solutions that we have not considered? What are these solutions you're referring to and how do they relate to this feature request for Starphleet? Maybe open a different issue related to logging and how it should be improved inside Starphleet?

I sincerely have no idea what you're aware of (singular you and plural).

fearphage commented 6 years ago

I think Pred loves infra

I wouldn't say that personally. I love simplicity, convenience, push instead of pull, tell instead of ask, etc. I am familiar with some tools that have delivered or been instrumental in delivering those values. I love the result/end game though and not the tools. The tools are merely a means to an end.

maybe should join the fire crew.

I'm more than happy to help lay the foundation to help us get to that point.

wballard commented 6 years ago

Oh -- things are 'pull' on purpose, it's self healing. The 'push' side is to github.

I say you love infra not as an indictment, but because you clearly are working on 'things that are off topic' from Client Service, and multi-projecting, on infra that doesn't have a clear payoff goal. Makes me think picking another project would align with your interests more.

On Wed, Apr 11, 2018 at 11:59 AM, Phred notifications@github.com wrote:

I think Pred loves infra

I wouldn't say that personally. I love simplicity, convenience, push instead of pull, tell instead of ask, etc. I am familiar with some tools that have delivered or been instrumental in delivering those values. I love the result/end game though and not the tools. The tools are merely a means to an end.

maybe should join the fire crew.

I'm more than happy to help lay the foundation to help us get to that point.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/wballard/starphleet/issues/361#issuecomment-380523781, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-HoINNWowkk1NB69RuSzRyBkGYyIEiks5tnjZXgaJpZM4TO-Me .