[Camps-users] question regarding setting up camp with interchange site

[Brian J. Miller]

Gert van der Spoel wrote:
>> -----Original Message-----
>> From: camps-users-bounces at endpoint.com [mailto:camps-users-
>> bounces at endpoint.com] On Behalf Of Jon Jensen
>> Sent: Monday, January 25, 2010 7:22 PM
>> To: camps-users at endpoint.com
>> Subject: Re: [Camps-users] question regarding setting up camp with
>> interchange site
>>
>> On Sun, 24 Jan 2010, Gert van der Spoel wrote:
>>
>>> My set up for interchange is as follows:
>>> - OS: Debian Linux
>>> - DB: Mysql DB 5.0.51a
>>> - WS: Apache 2.2.9  ( /etc/apache2/httpd.conf )
>>> - IC: Interchange 5.7.4  ( located at:  /opt/interchange/  - actually
>> that
>>> is symlink to /opt/interchange.5.7.4/   in case that matters)
>>> - CATROOT: /www/www.mydomain.com/catalog/
>>> - DOCROOT: /www/www.mydomain.com/htdocs
>>>
>>>  I read something regarding symlinking instead of copying.
>>>  In /www/www.mydomain.com/htdocs/images/  I have a couple of
>> directories
>>> with my images which I'd prefer to not copy.
>>>  How does that impact the copy-paths.yml? I saw something about
>> symlinking,
>>> but have the feeling that that would add
>>>  more complexity to the yml (I do not want to symlink all 'images'
>> just a
>>> couple of subdirectories).
>>>
>>> - CAMPHOME: /home/camp/    (here you will find /home/camp/bin/mkcamp
>> ..
>>> etc)
>>> - DEVHOME: /home/gert/     (under this user I'll want to be doing my
>>> development work)
>>>
>>> I'm having to put my interchange site still in git. I'm trying to
>> understand
>>> what is required to be in git to make things work well .. Should I
>> have
>>> *everything* in git?  All cfg's, images, etc? Any guidance in this
>> area is
>>> appreciated.
>>>
>>> For now I will opt for the 2 tier approach, so DEV and PROD  (no
>>> UAT/TEST/STAGE).  The CATROOT/DOCROOT represent my production
>> environment.
>>> Do I understand correctly that I'd have under /home/gert/xxx my
>> repository
>>> where I will make my changes which I will then deploy to my DEV and
>> PROD
>>> environments?
>>> So should I set up a /www/dev.mydomain.com/catalog  and
>>> /www/dev.mydomain.com/htdocs etc?
>> We have set up camps several different ways. Anything is possible. But
>> let
>> me describe what I feel is the best default way, which makes life the
>> easiest, first:
>>
>> Put everything in version control. Your Apache config includes
>> (whatever
>> parts you can do without hardcoded IP addresses or paths), Interchange
>> (minus the bin/interchange wrapper that localizes the paths), catalogs,
>> docroot (including all images if you can do it).
> 
> I'm looking for a bit more clarity on this one. 
> 
> Currently I have my production site in:
> /www/mydomain/catalog/ ....
> /www/mydomain/htdocs/  ...
> 
> (global) Apache config is:
> /etc/apache2/httpd.conf
> 
> (global) Mysql config is:
> /etc/mysql/my.cnf
> 
> (global) Interchange config is:
> /export/opt/interchange-5.7.4/interchange.cfg     (symlinked
> /opt/interchange/interchange.cfg)
> 
> 
> 
> I have some git things that I have cloned, such as interchange, in :
> /export/git/   

Cloned interchange, as in straight from github? or the like? aka what 
you would normally download?

> 
> 
> It there a certain location where you bunch that all together, before you go
> to /home/camp/-camptype-   (the place to store the camp data?).
> 

This largely depends on whether you already have a site in place or not. 
If yes then setting up the production instance as Jon indicated is 
probably the easiest as it is just a git repo itself. For that you would 
create a directory at /home/com_allcarmodels/live. In there you could do 
git init to set it as a git repo. Then you would just copy in your 
htdocs, interchange, catalogs, etc. After you commit that then you could 
clone that repository as a bare one to /home/camp. Alternatively you can 
go the other direction. Create the bare repo in 
/home/camp/com_allcarmodels, clone that repo to a temporary location 
(like /home/camp/com_allcarmodels/tmp) where you then put your 
interchange/, htdocs/, etc. and ultimately push back to the bare repo. 
Your preference probably depends on your abilities with git and whether 
you are starting with a fresh site or not. Our internal docs show it 
this way:

su - camp
mkdir --parents $camptype/$camptype.git
cd $camptype/$camptype.git
git --bare init --shared=group

Followed by

su - produser
mkdir -p tmp/holding
cd tmp/holding
git init
git remote add origin /home/camp/$camptype/$camptype.git
touch .gitignore
git add .
git commit -m "Initial commit"
git push --all

Which uses tmp/holding.

>  
>> If you have hundreds of GB of images, that probably won't work, and
>> then
>> you can use the copy-paths feature. But if you only have a few GB of
>> images, try putting them in version control. I've done it with up to 5
>> GB
>> or so and yes, it bloats your repo a bit, but makes a lot of other
>> things
>> easier.
> 
> It's currently about 1,5Gb images, but that will steadily grow .. But I
> think for the sake of getting a hang of the basics I will add them to the
> repository for now.

For me personally this decision is based on whether or not they should 
be versioned, which largely depends on whether they are updated by an 
outside force (like a web app or scripts) that won't (or can't) commit 
the changes. So, again a convention I've taken to using, I create two 
directories under htdocs/,

controlled/
uncontrolled/

The first is for images (and the like) that will be handled through git 
(aka version controlled) the other is for images (and other files) that 
won't. For anything that will be updated through the admin for instance, 
it goes in uncontrolled/ then I just setup copy paths directives for all 
of the subdirectories in uncontrolled/ and I am done. So I'd ask 
yourself whether your images are segregated enough that you can 
determine which are controlled and which aren't. If you have a 
subdirectory where you can guarantee that either they all will be 
controlled, or more likely they won't, then I'd put the latter case ones 
in copy paths. How you ultimately do it really is purely preference, Jon 
likes to (or needs to) see it all versioned as much as possible, for the 
newer projects I've been working on where we have the luxury of not 
dealing with legacy baggage I prefer to not ever have them in there.

> 
>  
>> Next, put everything in a single tree, organized like this camp of
>> mine:
>>
>> $ tree -L 1 camp99
>> camp99
>> |-- bin
>> |-- catalogs
>> |-- cgi-bin
>> |-- htdocs
>> |-- httpd
>> |-- interchange
>> |-- migrations
>> `-- pgsql
> 
> But this camp99 is in your /home/camp ? .. Or is this is your homedir?
> If in your homedir then I suppose we skip some steps as I suppose this would
> be all ending up there by doing mkcamp ?
> 

In his home dir, he was just showing the structure you'll end up with. 
So that is the structure you need to mimic when first setting up the 
repository as it will ultimately determine the locations mkcamp expects.

> 
>> The "migrations" directory is where we put SQL scripts for updating the
>> database schema during rollouts. We test them in a camp, and refresh
>> the
>> camp database from production and test again right before rolling the
>> schema change into production, so we're very sure it will work right
>> even
>> if weeks have passed since we first wrote the script. (And we have a
>> history of migration scripts in Git.)
>>
>> Finally, it's easiest if you set up a new home directory for production
>> and make it work the same way, checked out from Git:
>>
>> live
>> |-- bin
>> |-- catalogs
>> |-- htdocs
>> |-- interchange
>> `-- migrations
> 
> This is in your 'homedir' again?  Or somewhere else? And for that I assume
> you change around some configuration settings in your standard
> apache/interchange with regard to the paths it should follow?
> 

This is the "production" user homedir. It is a git clone of the bare 
repo but *NOT* a camp so to speak. It has the exact same structure as a 
camp but the files that are autogenerated by mkcamp are manually created 
for production and don't change (at least not regularly, if they do 
change then you have to edit their counterparts in /home/camp/...)

Yes some of the apache/ic settings change.

>  
>> Except we use the standard distribution Apache and database, so there's
>> no
>> cgi-bin, httpd, or pgsql there. (Those aren't in Git anyway; they're
>> created by mkcamp.)
>>
>> Did this make sense?
> 
> Not everything, but that could also be of a bit of lack of making use of git
> and how to sort things out in that area.
> 
>  



-- 
Brian J. Miller
End Point Corp.
brian at endpoint.com
W: 704-376-8292