feat: add helm for k8s and makefile

[henrywangx]

No description provided.

[casbin-bot]

@seriouszyx @tangyang9464 please review

[CLAassistant]

All committers have signed the CLA.

[hsluoyz]

@henrywangx plz fix:

[henrywangx]

Contributor License Agreement

@hsluoyz, I have signed with my account. Suppose it's ok now

[hsluoyz]

@ComradeProgrammer @Steve0x2a @seriouszyx plz review

[ComradeProgrammer]

Well I think I have some questions:

0. the port problems mentioned
1. do we really need to introduce makefile?
2. do we really need to introduce go vendor?
3. I think you may have some misunderstandings about the casdoor images (correct me if I am wrong plz). In the makefile I realize that you are trying to deploy the all-in-one image into k8s, which I think is improper. This image is supposed to be used for new users to experience casdoor with simple commands. This image integrates a database and have some special settings for the simplicication of deploying, thus inappropriate to be deployed into productive environments, like k8s
4. considering that it is very likely for potential users of casdoor to maintain their own customized image instead of our image to meet their own demand, I wonder whether it's proper and necessary to publish (or introduce) casdoor via helm, despite the truth that helm is very influential in cloud native area. In my own opinion, a more appropriate way may be giving out some simple config files to demostrate how to deploy it into k8s and what is needed to be noticed(for example, to mount the conf folder..) and it's protential customers' own duty and right to choose how to deploy it into k8s according to the various customized demands. A user who have reached the step of deploying casdoor into k8s should have their own deploying methods and convention, which is very unlikely to be identical to the configurations we write in helm charts.

[hsluoyz]

@henrywangx can you join the QQ group: 645200447 for discussion?

[henrywangx]

Well I think I have some questions:

0. the port problems mentioned
1. do we really need to introduce makefile?
2. do we really need to introduce go vendor?
3. I think you may have some misunderstandings about the casdoor images (correct me if I am wrong plz). In the makefile I realize that you are trying to deploy the all-in-one image into k8s, which I think is improper. This image is supposed to be used for new users to experience casdoor with simple commands. This image integrates a database and have some special settings for the simplicication of deploying, thus inappropriate to be deployed into productive environments, like k8s
4. considering that it is very likely for potential users of casdoor to maintain their own customized image instead of our image to meet their own demand, I wonder whether it's proper and necessary to publish (or introduce) casdoor via helm, despite the truth that helm is very influential in cloud native area. In my own opinion, a more appropriate way may be giving out some simple config files to demostrate how to deploy it into k8s and what is needed to be noticed(for example, to mount the conf folder..) and it's protential customers' own duty and right to choose how to deploy it into k8s according to the various customized demands. A user who have reached the step of deploying casdoor into k8s should have their own deploying methods and convention, which is very unlikely to be identical to the configurations we write in helm charts.

0. I will change the default port.
1. Yes, we should. For a production code, we need to define the build, containerized, deploy, ut, lint and some other necessary functions.
2. In my MR, I just remove it from .gitignore. That means I won't upload vendor.
3. It's default name for container. I will change the default name. And you could pass the env, if you need to customize the name. Both of registry and container name can be changed.
4. If some user don't like helm, they could add other commands into makefile(That's why I introduce the makefile). But If we don't support helm, we will lost many users.

[hsluoyz]

@henrywangx I'm OK to have better integration with k8s and helm, but this PR seems to add too many things that don't natively belong to Casdoor. Can we put this PR into some places like a casdoor-k8s-plugin? In the plugin repo, we can refer to Casdoor repo (this repo) via git submodules or other methods. What do you think?

[henrywangx]

@hsluoyz
This PR contains bellow things:

1. how to containerized casdoor;
2. enhance casdoor's code with golang-lint;
3. add helm chart for k8s;

All those things should be necessary, since I found it's too difficult to deploy casdoor into production env. If community think it's too heavy, just close this PR.

[casbin-bot]

🎉 This PR is included in version 1.17.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[hsluoyz]

@henrywangx thanks for your contribution! Can you also add docs to: https://casdoor.org/docs/deploy/k8s ?