RPM packaging possibilities

#1

Hello :slight_smile: Thank you for the OSS version. We’re using it inside our company network for almost 3 years now :slight_smile:

We don’t have (and don’t plan to have) Docker in production so we’ve been deploying Sentry in an old-fashioned way: as a virtualenv on a bare metal server under CentOS 6 and then 7. I have written a couple of Capistrano tasks for that.

This is rather messy though, and is not how Serious Software™ ought to be deployed. We’d like to package Sentry into nice RPM packages (for CentOS 7) and then install the packages to our production servers like the rest. We have our own RPM repositories and package many OSS for our servers already.

Now the thing is we’re not exactly big experts on Python and its ecosystem. We’ve tried to do some packaging via virtualenv but encountered many problems. I don’t want to go into details just now, but rather would like to know, from people who have experience with packaging, what would be the best approach to making an RPM. I mean, if we know the proper way to do it, and maybe some tools, we might succeed, and won’t need to bother you with the errors.

Any suggestions are very welcome. Thanks! :slight_smile:

1 Like
#2

Hi @vassilevsky,

Glad to hear you’re enjoying Sentry OSS for all those years, hope it’s been a pleasant journey :slight_smile:

I don’t know about RPM packaging at all but I believe checking out our Dockerfile would give you some ideas about the build and runtime system-level dependencies. Feel free to ping here about any specifics you need.

Btw, out of curiosity, what holds you back from using the Docker images on bare-metal? You don’t need anything complex like k8s or even docker-compose if you don’t want to? :slight_smile: Asking because we are going away from the “native” Python installations and more towards the Docker-based path as they provide the best for consistency, reliability, and ease of development. We are issuing new images per each commit on master, if that’d help you tip towards Docker :smiley:

#3

These are the main issues with Docker:

  • A Docker machine would stand out of the rest of the company infrastructure. A special snowflake.
  • There is not much Docker server administration experience in our ops team.
  • It’s unclear how we can apply our own (required) modifications if we run the Docker image:
    • Our own version of a Django package that adds LDAP authentication with role mapping;
    • Source code patch that removes INSERT errors from PostgreSQL server logs.
#4

For this, I think you can maintain a fork of the repo with the patches applied and build your own Docker images: docker build . -f docker/Dockerfile -t yourcompany/sentry:latest and use them via SENTRY_IMAGE=yourcompany/sentry:latest ./install.sh when installing.

For the other two, I cannot really comment :slight_smile:

#5

You could try to apply “alien” to my Debian package¹. Or use a tool similar to dh-virtualenv but for RPMs.

¹) https://github.com/1and1/debianized-sentry

2 Likes