search

Dev-Thought / nx-plugins

A collection of NX plugins baked with love ;)
MIT License
76 stars 7 forks source link

Kubernetes integration #49

Open iangregsondev opened 4 years ago

iangregsondev commented 4 years ago

Would be really nice if we could deploy our applications to Docker Hub - for example :-)

Deployments to cloud providers are great but ability to deploy to docker hub (or even a private docker registry) - would open up a lot.

MitkoTschimev commented 4 years ago

The first thing should be possible as far as I can see with a quick review: https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/docker/

The second point I would like to separate from this Feature Request. @iangregsondev can you do this, please?

iangregsondev commented 4 years ago

@MitkoTschimev Separate the feature request with regards to the github ?

Would you like me to submit a separate issue ?

iangregsondev commented 4 years ago

@MitkoTschimev I have separated the issue we were speaking about - I think.

Let me know if that is what you was referring to ?

https://github.com/Dev-Thought/nx-plugins/issues/50

I have also gone ahead an updated the title of the issue to exclude the github reference.

iangregsondev commented 4 years ago

The first thing should be possible as far as I can see with a quick review: https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/docker/

The second point I would like to separate from this Feature Request. @iangregsondev can you do this, please?

I presume the above library can just read in a dockerfile ?

https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/docker/#DockerBuild-dockerfile

I mean it looks like the library actually takes care of building a dockerfile via code as well. I think it would be also to just read in a dockerfile and publish it ?

MitkoTschimev commented 4 years ago

Yes, we have to define what is the scope of the issue now and how can an integration look like?

What do we expect at the end? Let's make a small brainstorming:

So nx-deploy-it will generate infrastructure to:

as example:

The next thing is to deploy it somehow somewhere otherwise it doesn't fit within this plugin. So what I could imaging is to provide the possibility additionally to run it as ESC on Fargate as an example or the other server instances on Azure or GCP. The plugin supports still the main idea ;) As 4th option of course a custom deployment by my self (using the docker image from the hub)

iangregsondev commented 4 years ago

I like the idea of the folder structure. Maybe this could be configurable as to the location of the Dockerfile.

It would also be beneficial to pass in environment variables for use while building the Dockerfile.

So these could be standard environment variables and also the ability to load via a .env file - docker has some information here https://docs.docker.com/compose/env-file/

With regards to deployment, I certainly think its beneficial to be able to deploy it to a cloud service - of course.

Although I do really see that deploying this to docker hub is a deployment.

Certainly in my case anyway, I am currently hosting inside a docker in Digital Ocean - but I have a service running to redeploy my docker services when the image changes in a registry.

There are 2 services that already support this, one that works on a pure docker container and another that works with docker swarm. I will paste them here for clarity

https://github.com/containrrr/watchtower

https://github.com/djmaze/shepherd

I think it would beneficial not allow a further deploy to a cloud service as you explained BUT i also think then the deployment could stop there - with the deployment to a registry.

I really do think that uploading the image to either docker hub or a private registry - is a real deployment.

I think some docker installations are locked down and probably not accessible from outside of the installation to perform the deployment.

For example, my production build is in Digital Ocean which of course has a public IP but I also run 2 development environments where the docker environment is NOT exposed externally - docker machine is used on a local IP.

I think it would be nice to offer a 2 stage deploy - a. To a docker registry b. To a cloud service using the image

It would be nice if both were opt in

MitkoTschimev commented 4 years ago

So this sounds really interesting and we will try to implement this as soon as possible ;) Then I see 2 steps here to fulfill and keep the plugin as clean as possible.

This Issue should solve to provide the application as docker image to a registry. I created an additional issue #52 and hope you can help us there to integrate a 4th provider to nx-deploy-it ;) because we don't have so much experience with digital ocean

MitkoTschimev commented 4 years ago

Someone has already created a plugin for docker creation:

https://github.com/gperdomor/nx-tools/tree/master/libs/nx-docker

maybe this could be reused here?

kauppfbi commented 4 years ago

Hi @MitkoTschimev and @iangregsondev,

I really like the idea to integrate Docker as well. Last year I already did something pretty similar. https://github.com/kauppfbi/ngx-deploy-docker

I am currently about to migrate it to a nx plugin (still within a private repo), but then I saw, that you are interested in it as well.

What do you think about a collaboration & integration in your repo? You can get in touch with me on twitter: https://twitter.com/kauppfbi

MitkoTschimev commented 4 years ago

Sure we can collaborate together here but I would use directly pulumi to create the docker images. They have already a package for this and than it’s in harmony with the whole other infrastructure as code and Easy to use with the cloud providers in combination for deployment.

iangregsondev commented 4 years ago

@MitkoTschimev Very nice - didn't realise that nx-docker existed. Looks great.

@kauppfbi I like what I see but an NX plugin would be great but as you say collaborating together which probably would be a really good way of obtaining the best possible implementation and plugins!

Nice.

kauppfbi commented 4 years ago

Hi,

Glad you're thinking the same.

I agree, using pulumi is better in this case. I just didn't know about it.

Can we have a short alignment to discuss about design, features and scope?

MitkoTschimev commented 4 years ago

Sure just my first thoughts when I dig into deeper: (Hope you are a bit familiar with nx-deploy-it)

Imagine this flow:

  1. Choose provider
  2. Users can choose between serverless or Kubernetes (I want directly to provide Kubernetes support) for backend applications.
  3. Is choosing Kubernetes than he would be asked if he wants to use a shared master -> Yes a lib in NX would be created with the IaC for the master cluster -> No a master would be created inside the app infrastructure folder
  4. Asking for the container registry related to the provider -> User types one -> this one will be used to push the new images -> User hits enter without providing will create a container registry in the same lib folder (registry container should be reused by all apps in the workspace)
  5. Creating IaC for the backend app (k8s service type load balancer) and pod with the image
  6. Create Dockerfile inside the infrastructure

nx run my-app:deploy -> and here we go 😀

GavinRay97 commented 4 years ago

Hey, thanks for creating a really awesome tool!

Is there still interest/work being done for Container deploy integration?

I would love to be able to add the ability to configure deploying a container, from a tag or a local Dockerfile image, since my common stack is usually:

If so, maybe could integrate the Cloud-agnostic package from Pulumi so that vendor-specific implementations don't all have to be written. This way, can just write a generic "container" resource and then say which Cloud provider it should be deployed to:

https://www.pulumi.com/docs/tutorials/cloudfx/ https://www.pulumi.com/docs/tutorials/cloudfx/service/

const cloud = require("@pulumi/cloud");

let service = new cloud.Service("pulumi-nginx", {
    containers: {
        nginx: {
            build: "./app",
            memory: 128,
            ports: [{ port: 80 }],
        },
    },
    replicas: 2,
});

// export just the hostname property of the container frontend
exports.url = service.defaultEndpoint.apply(e => `http://${e.hostname}`);
$ pulumi config set cloud:provider aws
$ pulumi config set aws:region us-east-1
$ pulumi config set cloud-aws:useFargate true
MitkoTschimev commented 4 years ago

I would be really happy if someone can take over for this feature because it's a big requirement which is still missing.

Currently I don't have any time because I'm working on 2 projects and the third one just released (fresh daddy) 🤣😀

So appreciate any help and I will definitely take my time to support / review everyone ;)

So this package sounds really nice and I never used it. So if you have experience then let's do it with the package. I already worked on kubernetes support and it was half done. I have to take a look if I committed it.

But the pulumi cloud package is more for simple containerization right? So we can provide it outside the kubernetes support. Not everyone needs kubernetes.

GavinRay97 commented 4 years ago

Congratulations on the baby!

I'm fairly hard up for time as well, but will take a look and see how much work this would be to integrate (I'm not very familiar with Angular schematics or nx haha).

But the pulumi cloud package is more for simple containerization right? So we can provide it outside the kubernetes support. Not everyone needs kubernetes.

The Cloud package provides generic resources that work across cloud providers. It's for everything from Serverless Lambda, Container, S3 Bucket, etc.

Instead of using a specific cloud library, like @pulumi/aws, you can define one generic resource and then set which cloud it should be deployed to.

https://github.com/pulumi/pulumi-cloud

The Pulumi Cloud Framework is in preview. It provides abstractions that can allow one to write a cloud-application on many different cloud providers (i.e. Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP)), using a common API.

There is an abstraction package, @pulumi/cloud, that defines the APIs common to all cloud providers. This provides a highly productive view on modern cloud architectures, akin to Java or .NET's approach to operating systems. Because these abstractions allow one to operate over different cloud platforms in a consistent manner, low level functionality and capabilities of the individual platforms are intentionally not exposed.

So for example, the API type: "API publishes an internet-facing HTTP API, for serving web applications or REST APIs."

let api = new API("myapi")
api.get("/", (req, res) => res.json({ hello: "world" }));
api.publish().url.then(url =>
  console.log(`Serving myapi at ${url}`)
);

If you set your config to AWS, this would create an AWS API Gateway/Lambda. On GCP, this would create a Cloud Function. On Azure... etc

So this way you can define cloud resources in a provider-independent manner, and it will translate it to the right resource on each platform.

This is a list of the generic Cloud resources: https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/cloud/#API

image

MitkoTschimev commented 4 years ago

Nice we should try it for the container and if it works really good than we could even refactor the serverless templates too. But let's start with the containers. I will create a new Issue for it.

62