규칙 위반: SQLite를 사용하여 웹 앱 데모

대부분의 잠재 사용자는 시간과 비용을 투자하기 전에 소프트웨어나 서비스를 사용해 보고 싶어할 것입니다. 일부 제품은 사용자에게 무료 평가판을 제공하는 것만으로도 훌륭하게 작동하는 반면, 다른 앱은 이미 샘플 데이터가 있는 상태에서 가장 잘 작동합니다. 종종 이것은 오래된 데모 계정이 작동하는 곳입니다.

그러나 데모 계정을 구현한 적이 있는 사람이라면 누구든지 관련된 문제를 증명할 수 있습니다. 인터넷에서 작동하는 방식을 알고 있습니다. 누구나 데이터를 입력할 수 있으며(제품에 의미가 있든 없든) 익명의 사용자나 봇이 추가한 콘텐츠가 다른 사람에게 불쾌감을 줄 가능성이 높습니다. 물론, 언제든지 데이터베이스를 재설정할 수 있지만 얼마나 자주, 언제입니까? 그리고 궁극적으로 그것이 정말로 문제를 해결합니까? SQLite를 사용하는 솔루션 입니다.

프로덕션 버전에 SQLite를 사용하지 않는 이유는 무엇입니까?

SQLite는 쓰기 명령 중에 전체 데이터베이스가 잠겨 있기 때문에 다중 스레드를 처리하지 않는 것으로 일반적으로 알려져 있습니다. 이것이 일반적인 프로덕션 환경에서 사용하지 말아야 하는 이유 중 하나입니다. 그러나 내 솔루션에서는 소프트웨어를 시연하는 각 사용자에 대해 별도의 SQLite 파일이 사용됩니다 . 즉, 쓰기 제한은 해당 사용자 한 명에게만 제한되지만 여러 동시 사용자(각각 고유한 데이터베이스 파일이 있음)는 이 제한을 겪지 않습니다. 이를 통해 사용자가 소프트웨어를 테스트할 수 있도록 제어된 경험을 제공하고 사용자가 보고 싶은 것을 정확하게 볼 수 있습니다.

이 튜토리얼은 2015년부터 SaaS 데모 웹 앱에 대해 성공적으로 실행해온 실제 솔루션을 기반으로 합니다. 이 튜토리얼은 Ruby on Rails(제가 선택한 프레임워크) 버전 3 이상을 위해 작성되었지만 기본 개념은 다음과 같아야 합니다. 다른 언어나 프레임워크에 적용할 수 있습니다. 사실, Ruby on Rails는 "구성보다 관례"라는 소프트웨어 패러다임을 따르기 때문에 다른 프레임워크, 특히 베어 언어(예: 스트레이트 PHP) 또는 데이터베이스 연결 관리 측면에서 많은 일을 하지 않는 프레임워크에서 구현하는 것이 훨씬 더 쉬울 수 있습니다. .

즉, 이 기술은 Ruby on Rails에 특히 적합합니다. 왜요? 대부분의 경우 "데이터베이스 불가지론"이기 때문입니다. 즉, Ruby 코드를 작성하고 문제 없이 데이터베이스 간에 전환할 수 있어야 합니다.

이 프로세스의 완성된 버전 샘플은 GitHub에서 다운로드할 수 있습니다.

첫 번째 단계: 배포 환경

나중에 배포할 예정이지만 Ruby on Rails는 기본적으로 개발, 테스트 및 프로덕션 환경으로 나뉩니다. 이 목록에 프로덕션 환경과 거의 동일하지만 다른 데이터베이스 설정을 사용할 수 있는 앱용 새 데모 환경을 추가할 것입니다.

Rails에서 config/environments/production.rb 파일을 복제하여 새 환경을 만들고 이름을 demo.rb 로 바꿉니다. 데모 환경은 프로덕션과 같은 설정에서 사용되므로 이 새로운 환경에 대해 많은 구성 옵션을 변경할 필요가 없을 수도 있습니다. 하지만 config.assets.compile 을 false 에서 true 로 변경하면 미리 컴파일해야합니다.

Rails 4 이상을 실행하는 경우 데모 환경을 위한 secret_key_base 를 추가하기 위해 config/secrets.yml 도 업데이트해야 합니다. 세션이 각 환경 간에 고유하도록 하여 앱을 더욱 안전하게 보호하려면 이 비밀 키를 프로덕션과 다르게 만드십시오.

다음으로 config/database.yml 에서 데이터베이스 구성을 정의해야 합니다. 데모 환경은 주로 다음 섹션에서 다룰 복제된 데이터베이스를 사용하지만 데모에 사용할 기본 데이터베이스 파일과 설정을 정의해야 합니다. config/database.yml 에 다음을 추가합니다.

 demo: adapter: sqlite3 pool: 5 timeout: 5000 database: db/demo.sqlite3

Rails에서 새로운 데모 환경에서 SQLite3를 사용할 수 있는지 확인하기 위해 Gemfile 을 확인할 수도 있습니다. 여러 가지 방법으로 설정할 수 있지만 다음과 같이 보일 수 있습니다.

 group :development, :test, :demo do gem 'sqlite3' end

데이터베이스가 구성되면 rake db:migrate RAILS_ENV=demo 다음 원하는 대로 데이터베이스에 데이터를 시드해야 합니다(시드 파일에서 가져온 것이든, 새 데이터를 수동으로 입력하든, development.sqlite3 파일을 복제하든 상관없이). 이 시점에서 명령줄에서 rails server -e demo 를 실행하여 모든 것이 제대로 작동하는지 확인해야 합니다. 새 데모 환경에서 서버를 실행하는 동안 테스트 데이터가 원하는 대로인지 확인할 수 있지만 나중에 언제든지 돌아와서 해당 콘텐츠를 편집할 수 있습니다. 데모 데이터베이스에 콘텐츠를 추가할 때 파일이 가능한 한 작도록 깨끗한 ​​데이터 집합을 만드는 것이 좋습니다. 그러나 다른 데이터베이스에서 데이터를 마이그레이션해야 하는 경우 데이터 덤프 및 복원을 위한 데이터베이스 독립적 형식을 만드는 YamlDb를 권장합니다.

Rails 애플리케이션이 예상대로 실행되고 있다면 다음 단계로 넘어갈 수 있습니다.

두 번째 단계: 데모 데이터베이스 사용

이 튜토리얼의 필수적인 부분은 각 세션이 다른 SQLite 데이터베이스 파일을 사용할 수 있도록 하는 것입니다. 일반적으로 애플리케이션은 모든 사용자에 대해 동일한 데이터베이스에 연결하므로 이 작업에 추가 코드가 필요합니다.

Ruby on Rails가 데이터베이스를 전환할 수 있도록 하려면 먼저 다음 4가지 개인 메서드를 application_controller.rb 에 추가해야 합니다. 또한 모든 페이지 로드 시 올바른 데모 데이터베이스를 참조하는 논리가 호출되도록 set_demo_database 메서드에 대한 이전 필터를 정의해야 합니다.

 # app/controllers/application_controller.rb # use `before_filter` for Rails 3 before_action :set_demo_database, if: -> { Rails.env == 'demo' } private # sets the database for the demo environment def set_demo_database if session[:demo_db] # Use database set by demos_controller db_name = session[:demo_db] else # Use default 'demo' database db_name = default_demo_database end ActiveRecord::Base.establish_connection(demo_connection(db_name)) end # Returns the current database configuration hash def default_connection_config @default_config ||= ActiveRecord::Base.connection.instance_variable_get("@config").dup end # Returns the connection hash but with database name changed # The argument should be a path def demo_connection(db_path) default_connection_config.dup.update(database: db_path) end # Returns the default demo database path defined in config/database.yml def default_demo_database return YAML.load_file("#{Rails.root.to_s}/config/database.yml")['demo']['database'] end

모든 서버 세션에는 다른 데이터베이스가 있으므로 세션 변수에 데이터베이스 파일 이름을 저장합니다. 보시다시피 session[:demo_db] 를 사용하여 사용자의 특정 데이터베이스를 추적하고 있습니다. set_demo_database 메소드는 세션 변수에 설정된 데이터베이스에 연결을 설정하여 사용할 데이터베이스를 제어합니다. default_demo_database 메소드는 단순히 database.yml 구성 파일에 정의된 대로 데이터베이스의 경로를 로드합니다.

베어 언어를 사용하는 경우 이 시점에서 새 데이터베이스를 가리키도록 데이터베이스 연결 스크립트를 업데이트하고 다음 섹션으로 이동할 수 있습니다. Rails에서는 "convention over configuration" 소프트웨어 패러다임을 따르기 때문에 몇 가지 단계가 더 필요합니다.

세 번째 단계: SQLite 파일 복제

이제 앱이 새 데이터베이스를 사용하도록 설정되었으므로 새 데모 세션에 대한 트리거가 필요합니다. 간단하게 하기 위해 기본 "데모 시작" 버튼을 사용하여 시작하십시오. 이름과 이메일 주소(영업 팀의 후속 조치 등을 위해) 또는 여러 가지를 수집하는 양식을 만들 수도 있습니다.

Rails 규칙에 따라 새 '데모' 컨트롤러를 만듭니다.

 rails generate controller demos new

다음으로, 새 컨트롤러 작업을 가리키도록 경로를 업데이트하고 프로덕션 환경에서 호출되지 않도록 조건부로 래핑해야 합니다. 원하는 대로 경로 이름을 지정하거나 표준 Rails 규칙을 사용하여 이름을 지정할 수 있습니다.

 if Rails.env == 'demo' get 'demos/new', as: 'new_demo' post 'demos' => 'demos#create', as: 'demos' end

다음으로 views/demos/new.html.erb 에 매우 기본적인 형식을 추가해 보겠습니다. 캡처할 추가 양식 필드를 추가할 수 있습니다.

 <h1>Start a Demo</h1> <%= form_tag demos_path, method: :post do %> <%= submit_tag 'Start Demo' %> <% end %>

마법은 create 작업에서 발생합니다. 사용자가 이 경로에 제출하면 작업은 새로운 고유한 파일 이름으로 demo.sqlite3 파일을 복사하고 세션 변수를 설정하고 사용자를 로그인(해당되는 경우)한 다음 사용자를 적절한 페이지로 리디렉션합니다(이를 '계기반').

 class DemosController < ApplicationController def new # Optional: setting session[:demo_db] to nil will reset the demo session[:demo_db] = nil end def create # make db/demos dir if doesn't exist unless File.directory?('db/demos/') FileUtils.mkdir('db/demos/') end # copy master 'demo' database master_db = default_demo_database demo_db = "db/demos/demo-#{Time.now.to_i}.sqlite3" FileUtils::cp master_db, demo_db # set session for new db session[:demo_db] = demo_db # Optional: login code (if applicable) # add your own login code or method here login(User.first) # Redirect to wherever you want to send the user next redirect_to dashboard_path end end

이제 rails server -e demo 실행을 사용하여 서버를 다시 시작하여 로컬에서 데모 코드를 시험해 볼 수 있습니다.

서버가 이미 실행 중인 경우 프로덕션 서버와 같이 코드를 캐시하도록 구성되어 있으므로 변경 사항에 대해 서버를 다시 시작해야 합니다.

모든 코드가 예상대로 작동하면 변경 사항을 버전 제어에 커밋하고 demo.sqlite3 파일을 커밋하지만 db/demos 디렉토리의 파일은 커밋하지 마십시오. git을 사용하는 경우 .gitignore 파일에 다음을 추가하기만 하면 됩니다.

데모 사용자로부터 추가 정보(예: 이름 및/또는 이메일)를 수집하려는 경우 데모 데이터베이스를 신뢰할 수 없기 때문에 API를 통해 해당 정보를 기본 애플리케이션이나 다른 판매 파이프라인으로 보내고 싶을 것입니다. (재배포할 때마다 재설정됨).

 !/db/demo.sqlite3 db/demos/*

최종 단계: 데모 서버 배포

이제 로컬에서 작동하는 데모 설정이 있으므로 모든 사람이 사용할 수 있도록 배포하고 싶을 것입니다. 모든 앱은 다르지만 데모 앱은 별도의 서버에 있으므로 프로덕션 앱으로 도메인(예: demo.myapp.com)을 사용하는 것이 좋습니다. 이렇게 하면 두 환경을 격리된 상태로 유지할 수 있습니다. 또한 SQLite 파일이 서버에 저장되기 때문에 Heroku와 같은 서비스는 파일 시스템에 대한 액세스를 제공하지 않으므로 작동하지 않습니다. 그러나 거의 모든 VPS 공급자(예: AWS EC2, Microsoft Azure 등)를 계속 사용할 수 있습니다. 자동화된 편리함이 마음에 들면 VPS로 작업할 수 있는 다른 서비스로서의 플랫폼 옵션이 있습니다.

배포 프로세스에 관계없이 앱에 데모 SQLite 파일을 저장하는 디렉터리에 대한 적절한 읽기/쓰기 권한이 있는지 확인해야 할 수도 있습니다. 이것은 수동으로 처리하거나 배포 후크를 사용하여 처리할 수 있습니다.

SQLite가 작동하지 않습니다. 다른 데이터베이스 시스템은 어떻습니까?

두 개의 앱이 유사하게 생성되지 않으며 데이터베이스 요구 사항도 동일하지 않습니다. SQLite를 사용하면 데이터베이스를 빠르게 복제할 수 있고 파일을 버전 제어에 저장할 수 있다는 이점이 있습니다. 저는 SQLite가 대부분의 상황(특히 Rails의 경우)에서 작동할 것이라고 생각하지만 SQLite가 애플리케이션의 요구 사항에 적합하지 않을 수 있는 상황이 있습니다. 다행히도 다른 데이터베이스 시스템에서 위와 동일한 개념을 계속 사용할 수 있습니다. 데이터베이스를 복제하는 프로세스는 시스템마다 약간씩 다르지만 MySQL용 솔루션에 대해 간략히 설명하고 PostgreSQL 등에도 유사한 프로세스가 존재합니다.

위에서 다룬 대부분의 방법은 추가 수정 없이 작동합니다. 그러나 버전 제어에 SQLite 파일을 저장하는 대신 mysqldump (또는 PostgreSQL의 경우 pg_dump )를 사용하여 데모 경험에 사용하려는 콘텐츠가 있는 데이터베이스의 SQL 파일을 내보내야 합니다. 이 파일은 버전 관리에도 저장해야 합니다.

이전 코드의 유일한 변경 사항은 demos#create 작업에서 찾을 수 있습니다. SQLite3 파일을 복사하는 대신 컨트롤러 작업은 새 데이터베이스를 만들고 해당 데이터베이스에 sql 파일을 로드하고 필요한 경우 데이터베이스 사용자에게 권한을 부여합니다. 액세스 권한 부여의 세 번째 단계는 데이터베이스 관리자 사용자가 앱이 연결하는 데 사용하는 사용자와 다른 경우에만 필요합니다. 다음 코드는 표준 MySQL 명령을 사용하여 이러한 단계를 처리합니다.

 def create # database names template_demo_db = default_demo_database new_demo_db = "demo_database_#{Time.now.to_i}" # Create database using admin credentials # In this example the database is on the same server so passing a host argument is not require `mysqladmin -u#{ ENV['DB_ADMIN'] } -p#{ ENV['DB_ADMIN_PASSWORD'] } create #{new_demo_db}` # Load template sql into new database # Update the path if it differs from where you saved the demo_template.sql file `mysql -u#{ ENV['DB_ADMIN'] } -p#{ ENV['DB_ADMIN_PASSWORD'] } #{new_demo_db} < db/demo_template.sql` # Grant access to App user (if applicable) `mysql -u#{ ENV['DB_ADMIN'] } -p#{ ENV['DB_ADMIN_PASSWORD'] } -e "GRANT ALL on #{new_demo_db}.* TO '#{ ENV['DB_USERNAME'] }'@'%';"` # set session for new db session[:demo_db] = new_demo_db # Optional: login code (if applicable) # add your own login code or method here login(User.first) redirect_to dashboard_path end

PHP를 포함한 다른 많은 언어와 마찬가지로 Ruby는 백틱을 사용하여 코드 내에서 쉘 명령(예: `ls -a` )을 실행할 수 있습니다. 그러나 이를 주의해서 사용해야 하며 악의적으로 삽입된 코드로부터 서버를 보호하기 위해 명령에 사용자에게 표시되는 매개변수나 변수를 삽입할 수 없도록 해야 합니다. 이 예에서는 새 데이터베이스를 생성하는 유일한 방법인 MySQL 명령줄 도구와 명시적으로 상호 작용합니다. 이것은 Ruby on Rails 프레임워크가 새 데이터베이스를 생성하는 것과 같은 방식입니다. ENV['DB_ADMIN'] 및 ENV['DB_ADMIN_PASSWORD'] 를 자신의 환경 변수로 바꾸거나 데이터베이스 사용자 이름을 설정하는 다른 방법으로 바꾸십시오. 관리자 사용자가 앱 사용자와 다른 경우 ENV['DB_USERNAME'] 에 대해서도 동일한 작업을 수행해야 합니다.

이것이 MySQL로 전환하는 데 필요한 전부입니다! 이 솔루션의 가장 분명한 장점은 데이터베이스 시스템 간의 다른 구문에서 나타날 수 있는 잠재적인 문제에 대해 걱정할 필요가 없다는 것입니다.

결국 편의성과 속도가 아닌 기대되는 품질과 서비스를 바탕으로 최종 결정을 내리게 되며 반드시 가격대만으로 결정되는 것은 아니다.

마지막 생각들

이것은 새 데모 서버로 수행할 수 있는 작업의 시작점일 뿐입니다. 예를 들어 마케팅 웹사이트에 "XYZ 기능 사용해보기"에 대한 링크가 있을 수 있습니다. 이름이나 이메일이 필요하지 않은 경우 demos#create 메소드를 /demos/?feature=xyz 와 같은 링크와 연결할 수 있으며 작업은 대시보드가 ​​아닌 원하는 기능 및/또는 페이지로 단순히 리디렉션됩니다. 위의 예.

또한 개발 및 데모 환경에 SQLite를 사용하는 경우 항상 버전 제어에 이 샘플 데이터베이스를 사용하면 모든 개발자가 로컬 개발, 테스트 환경 또는 품질 보증 테스트에 사용할 깨끗한 데이터베이스에 액세스할 수 있습니다. 가능성은 무한합니다.

GitHub에서 완성된 데모를 다운로드할 수 있습니다.