Offline Install


(Andrew Meyer) #1

Is there currently an easy way to install Discourse offline, or from behind a firewall which doesn’t allow internet access? From what I’ve seen of discourse_docker’s Dockerfile, it looks like the default install method is heavily reliant upon network access.

I ask this because I am trying to deploy an internal Discourse server for my company in a very similar network environment.

More details:

  • Our development machines do have internet access, but the machines we are deploying Discourse to do not
  • Our deployment does have access to resources inside our network, including a mirror of Ubuntu’s APT repo
  • It is feasible for us to create internal mirrors of git repositories and tarballs which Discourse may depend on
  • Our normal deployment process is automated using Chef recipes

So what’s the deal? Is there an easy way of doing this, or do I have to just copy everything to behind the firewall and write the Chef recipes necessary to install Discourse and all it’s dependencies myself?


Authentication is required error when pulling repo
(lid) #2

The easiest way that I can think of is that you generate the container on a more permissible environment.
Then backup the docker image, and import it inside the more restrictive environment.

At one point or another you need internet access to get the dependencies, so you might as well use the power of docker.

as to upgrades and updates, this is a different story.


#3

Or temporarily move your server outside your firewall (unlikely I am sure) but you have to have clear internet access to install via the docker method. Development machines have access to the internet but production does not? I’m sure there is a reason, maybe this is an internal project of some sort.

Maybe you can have your server admin pinhole the network for the docker and git pull sources?


(Andrew Meyer) #4

Development machines have access to the internet but production does not? I’m sure there is a reason, maybe this is an internal project of some sort.

I’m not 100% clear on the exact reasoning, but I think it’s mostly done out of a desire to maintain some level of control of the software running inside the company firewall (for reasons of security and compliance with copyright law), and to prevent reliance on external services for deployment of internal software (which is the more relevant part, from my perspective).

I think the primary motivation for the second reason (avoiding reliance on external services) is that my company often has to do maintenance on / manufacture parts for old equipment that we built 15+ years ago. In such a situation, it’s helpful to be able to resurrect any development tools we were using at the time we first built the equipment, and that might not be possible if the set up process for those tools was relying on external resources which no longer exist. (Maybe that’s not quite as relevant for a discussion board as for other tools, but nonetheless it’s still a factor.)

Or temporarily move your server outside your firewall (unlikely I am sure) but you have to have clear internet access to install via the docker method.

With the goals above in mind, I don’t think a work-around for giving production machines temporary internet access would be a suitable solution.

The easiest way that I can think of is that you generate the container on a more permissible environment. Then backup the docker image, and import it inside the more restrictive environment.

That’s possible, Docker images aren’t very easy to change compared to something like a Chef recipe though. From the standpoint of being able to maintain a Discourse server sometime in the far future without relying on external services, I’m not sure that’s such a good idea. I guess it is a possibility though.


Anyway, I’m probably just going to build the server out with Chef, since that seems like a more robust and flexible solution. Thanks for your help though.


(Sam Saffron) #5

I am completely not follow this, example please?


(Andrew Meyer) #6

E.g. It’s better to go tweak a Chef recipe than to SSH into the image and perform a bunch of manual steps (which are difficult to reproduce consistently).


(Sam Saffron) #7

cough hmmm I am now really confused about what your are saying here. All our docker setups are template based.


(Andrew Meyer) #8

Interesting, I didn’t see those templates until now. I was just looking at the Dockerfile, which at first glance seems like a total mess.

How might I use those template files to change the environment/configuration of a Discourse image? Is there any existing documentation on that that I can go read?


(Sam Saffron) #9

You can read about pups here: GitHub - discourse/pups: Simple yaml based bootstrapper for Linux machines

You can see all our templates used to install discourse here: discourse_docker/templates at master · discourse/discourse_docker · GitHub


(Andrew Meyer) #10

Hmm, so it’s like a simple, lightweight version of Chef/Puppet? Interesting.

I just skimmed through the source code for ./launcher, and I think I’m starting to see how this works.

When I run ./launcher bootstrap:

  1. The launcher downloads a pre-built docker image from outside the firewall. That image was pre-built from the contents of the base Dockerfile.
  2. The launcher executes all the pups templates located in /templates from inside the docker image.

Is that correct?


(MorphZan) #11

Can you follow the development install process and install everything while online and then take the machine offline and run discourse offline in an environment that has no internet access?