search

RocketChat / feature-requests

This repository is used to track Rocket.Chat feature requests and discussions. Click here to open a new feature request.
21 stars 9 forks source link

option to run rocketchat disconnected without internet access #168

Open RonnyMaas opened 5 years ago

RonnyMaas commented 5 years ago

Is your feature request related to a problem? Please describe. Yes, rocketchat installed with stable helm chart can't start in kubernetes without internet access. Also it doesn't log anything that indicates that it can't start without internet access. It just keeps restarting because healthcheck on port 3000 fails.

Describe the solution you'd like I have a disconnected private cloud and want to be able to run rocketchat in kubernetes without internet access.

Describe alternatives you've considered

Additional context

sampaiodiego commented 5 years ago

rocket.chat itself doesn't depend on internet access to run, I'm not sure what the heml chart actually does.

@geekgonecrazy @LuluGO is there anything the helm chart does that needs internet?

geekgonecrazy commented 5 years ago

If the chart is local and the machine has the docker images needed by the helm chart inside the cluster... I don’t believe it needs internet access.

So you would need to transport the rocket.chat and mongo images to all of the nodes in the cluster.. or make them available in a local repo and make sure to change images in the chart to use your repo.

From what I can tell there is nothing else we can do inside of helm to make this possible. Since the docker image must be there.. and helm doesn’t embed the images inside.

If you are aware of something please let us know.

RonnyMaas commented 5 years ago

I will check. I know all images are pulled, mongodb is up and rocketchat tries to start. Only problem is that rocketchat pod keeps restarting because of failed healthchecks on port 3000. The pod is up for some minutes and then restarts because of the failed healthcheck But when I added the proxy env for the rocketchat pod it starts every time and has no restarts anymore.

RonnyMaas commented 5 years ago

Before the http_proxy env the last message in the pod log was:

Updating process.env.MAIL_URL

With proxy env it now starts and shows started banner. But is doesn't seem to be an issue with the MAIL_URL because on some restarts without proxy env. The following grid messages where printed before the MAIL_URL messages and sometimes after the MAIL_URL message.

Using GridFS for custom sounds storage Using GridFS for custom emoji storage

RonnyMaas commented 5 years ago

If the chart is local and the machine has the docker images needed by the helm chart inside the cluster... I don’t believe it needs internet access.

So you would need to transport the rocket.chat and mongo images to all of the nodes in the cluster.. or make them available in a local repo and make sure to change images in the chart to use your repo.

From what I can tell there is nothing else we can do inside of helm to make this possible. Since the docker image must be there.. and helm doesn’t embed the images inside.

If you are aware of something please let us know.

Whe are completely disconnected (unless we enable internet access as I have done for this issue). Whe mirror al docker registries, packages and helm chart repos. So we don't need internet for deploying charts, images or the install of packages.

sampaiodiego commented 5 years ago

Can you try increasing the health check initial delay? or just increase the check interval.. or even disable it for testing purposes.. because rocket.chat doesn't require internet access to start up.

RonnyMaas commented 5 years ago

Can you try increasing the health check initial delay? or just increase the check interval.. or even disable it for testing purposes.. because rocket.chat doesn't require internet access to start up.

With internet access it starts every time. Without it, it won't. But that is not really true. Because for some reason when I left work and wanted to try to solve the problem the next day, I saw that it was running but took 30 restarts to get in that state. Then I deleted the pod and after 64 restarts it was running again and the next test took 141 restarts until it was running again. But I really don't have a clue why that happens. After that I thought maby I should do something stupid because I checked everything and tried everything and added the proxy env. Since then every deploy is ok.

RonnyMaas commented 5 years ago

I know this sounds unbelievable

RonnyMaas commented 5 years ago

This will not be the problem, but I also see that rocketchat tries to use icons for pages from internet url's.

Error while handling the setting of the avatar from a url (https://secure.gravatar.com/avatar/2be8e1fc7e8cc9c841a3232a3e1d121c?default=404&size=200) for alerts-dev5: { Error: tunneling socket could not be established, cause=getaddrinfo ENOTFOUND shs shs:80 at ClientRequest.onError (/app/bundle/programs/server/npm/node_modules/meteor/http/node_modules/tunnel-agent/index.js:177:17) at Object.onceWrapper (events.js:315:30) at emitOne (events.js:116:13) at ClientRequest.emit (events.js:211:7) at Socket.socketErrorListener (_http_client.js:387:9) at emitOne (events.js:116:13) at Socket.emit (events.js:211:7) at emitErrorNT (internal/streams/destroy.js:64:8) at _combinedTickCallback (internal/process/next_tick.js:138:11) at process._tickDomainCallback (internal/process/next_tick.js:218:9) code: 'ECONNRESET' }

RonnyMaas commented 5 years ago

Also although the pod/container can connect to the internet. Apps can't be downloaded.

menu options for app and marketplace give error "Cannot read property 'data' of undefined"

RonnyMaas commented 5 years ago

I20190818-10:31:17.338(0) server.js:212 API ➔ debug GET: /api/apps?marketplace=true I20190818-10:31:17.396(0) server.js:212 API ➔ debug get threw an error: TypeError: Cannot read property 'data' of undefined at Object.get (app/apps/server/communication/rest.js:80:86) at Object._internalRouteActionHandler [as action] (app/api/server/api.js:278:31) at Route.share.Route.Route._callEndpoint (packages/nimble_restivus/lib/route.coffee:150:32) at packages/nimble_restivus/lib/route.coffee:59:33 at packages/simple_json-routes.js:98:9 I20190818-10:31:17.397(0) server.js:212 API ➔ debug Failure { statusCode: 400, body: { success: false, error: 'Cannot read property \'data\' of undefined', stack: undefined } }

RonnyMaas commented 5 years ago

If I increase read

Can you try increasing the health check initial delay? or just increase the check interval.. or even disable it for testing purposes.. because rocket.chat doesn't require internet access to start up.

I tried that. Then it works, but then it takes the pod more them 5 minutes to start. With proxy setting this is always less then 30 seconds.

RonnyMaas commented 5 years ago

It takes then every time more then 5 minutes (a lot of downtime when you change something that requires a restart ) also if I have disabled all settings that require internet access in the admin page.

RonnyMaas commented 5 years ago

Also without http_proxy, uploaded apps with nodejs rc-apps client and rocketchat apps development mode enabled. Apps are not shown under apps and can't be enabled because it needs to be visible under apps to be able to enable it

geekgonecrazy commented 5 years ago

Apps do require access to the marketplace which would require internet. We are working on making it possible to download apps and then side load them. But that experience is not yet complete.

But Internet access is not required by Rocket.Chat its self to start up.

As to your slow startups.. I'm not sure I think this might depend on your exact setup. Because startup on a reasonably powered server with a core or two and a couple of gigs of available memory starts in less then 1 minute.

RonnyMaas commented 5 years ago

Apps do require access to the marketplace which would require internet. We are working on making it possible to download apps and then side load them. But that experience is not yet complete.

But Internet access is not required by Rocket.Chat its self to start up.

As to your slow startups.. I'm not sure I think this might depend on your exact setup. Because startup on a reasonably powered server with a core or two and a couple of gigs of available memory starts in less then 1 minute.

With no proxy setting start up could take hours. I have seen it start after 142 restarts when i had no proxy setting. But with proxy settings it starts in less then 60 seconds, start time depends on if image was already downloaded on worker node or not.

Ik looks like it's hitting timeouts on trying to connect to something (internet related) and if the timeout takes longer then the health or self checks then the pod restarts.