Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reloading configuration still takes unnecessarily long #212

Closed
DonMartin76 opened this issue Jul 18, 2019 · 1 comment
Closed

Reloading configuration still takes unnecessarily long #212

DonMartin76 opened this issue Jul 18, 2019 · 1 comment
Milestone

Comments

@DonMartin76
Copy link
Member

On Kubernetes environments, the restarting of the wicked environment after a configuration reload still takes unnecessarily long, even after implementing #191.

The solution of this may lie in the Kubernetes configuration, and in the liveness and readiness probes. As shows on the wicked.box environment, restarts can be pretty quick (just 2-3 seconds usually).

Explore whether using either nodemon or pm2 can be a solution for the non-api containers. The api container will still need a full reload, as the git clone happens in the startup script of the container - at least currently.

@DonMartin76 DonMartin76 added this to the 1.0.0-rc.8 milestone Jul 18, 2019
DonMartin76 added a commit to apim-haufe-io/wicked.api that referenced this issue Jul 18, 2019
... instead of letting e.g. Kubernetes handle the restart. Advantages:
- Much quicker restart
- Kubernetes does not count a reload as a full crash

See Haufe-Lexware/wicked.haufe.io#212
DonMartin76 added a commit to apim-haufe-io/wicked.env that referenced this issue Jul 18, 2019
@DonMartin76
Copy link
Member Author

This had a very simple and straightforward fix: Surround calling npm start with a forever.sh bash script, which just restarts the process. This makes Kubernetes usually not even detect that something has restarted.

The same thing could be applied to the api container as well - there is now a semaphore which checks whether a stopped node process is due to a deliberate reload, or not. If it is, the container is kept up, the git repo is recloned, and everything just restarts, without e.g. Kubernetes or docker agent interaction.

Will land in 1.0.0-rc.8.

maksimlikharev pushed a commit to clarivate/wicked.api that referenced this issue Jul 29, 2019
* adding group for the subscription/approval events (#22)

* Bump to version 1.0.0-rc.5

* Fixes Haufe-Lexware/wicked.haufe.io#196

* Fixes Haufe-Lexware/wicked.haufe.io#198

* Bump to version 1.0.0-rc.6

* Update docker group to adapt to new Jenkins

* Use classical pipeline again (test)

* Try this on the RD jenkins

* Allow loading of javascript file in static content (#24)

* Change back to "docker" agent

* Take out SonarQube for the time being

* Log in once to make sure docker login is done

* Bump to version 1.0.0-rc.7

* Enable switching off health checks

* Bump to version 1.0.0-rc.8

* Infinite loop inside docker container...
... instead of letting e.g. Kubernetes handle the restart. Advantages:
- Much quicker restart
- Kubernetes does not count a reload as a full crash

See Haufe-Lexware/wicked.haufe.io#212

* honor host (#25)

* Partly fixes Haufe-Lexware/wicked.haufe.io#216
maksimlikharev pushed a commit to clarivate/wicked.env that referenced this issue Jul 29, 2019
* Update jQuery, move to wicked-saml2-js (with isPassive fix)

* Bump to version 1.0.0-rc.5

* Bump to 1.0.0-rc.5

* Bump to version 1.0.0-rc.6

* Test jenkins from rd

* Move back to "docker" agents

* Update version of package.all.json

* Bump to version 1.0.0-rc.7

* Update package.all.json

* Update package.all.json (added LDAP client)

* Bump to version 1.0.0-rc.8

* Make containers reload themselves, without crashing

See Haufe-Lexware/wicked.haufe.io#212

* Also adapt alpine Dockerfile with forever.sh

* Updated package.all.json
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant